-
Type:
Problem report
-
Resolution: Unresolved
-
Priority:
Trivial
-
None
-
Affects Version/s: 7.4.11, 7.4.12
-
Component/s: Server (S)
-
None
-
S26-W28/29
Hello,
we are running Zabbix on an Alpine Linux 3.24 VM. On Thursday the "zabbix_server: http agent poller" started to leak memory.
Time history:
- 2026-06-11 06:09:55: Update Zabbix 7.4.5-r7 -> 7.4.11-r0
- 2026-06-24 06:45:00: Reboot
- 2026-07-09 07:29:53: Update Postfix, update hostsystem and reboot.
Zabbix started memleaking - 2026-07-13 07:14:38: Update Zabbix 7.4.11-r0 -> 7.4.12-r0, raised cache sizes
Still memleaking ([compiling options](https://gitlab.alpinelinux.org/alpine/aports/-/blob/3.24-stable/community/zabbix/APKBUILD))
I am not sure, what caused this problem. It might not even be caused by the update/versions itself, as the problem started with a huge delay. The process keeps growing about 1MB every second.
Current config (after increasing the cache sizes):
zabbix-01:~# cat /etc/zabbix/zabbix_server.conf | egrep -ve '^($|DBPass|#)' LogFile=/var/log/zabbix/zabbix_server.log LogFileSize=50 DebugLevel=3 PidFile=/var/run/zabbix/zabbix_server.pid DBName=zabbix DBName=zabbix DBUser=zabbix DBUser=zabbix StartPollers=35 StartPollers=35 StartPingers=8 StartPingers=8 StartVMwareCollectors=5 VMwareTimeout=30 CacheSize=512M TrendCacheSize=512M ValueCacheSize=2G Timeout=12 Timeout=12 ExternalScripts=/etc/zabbix/externalscripts FpingLocation=/usr/sbin/fping LogSlowQueries=3000 StatsAllowedIP=127.0.0.1 StartHTTPAgentPollers=2 zabbix-01:~#
Ignore the shared memory and and only dump memory areas, that are changing:
cat /proc/1882/maps | grep ' 0[ ]*$' > t1 # sleep a minute or two cat /proc/1882/maps | grep ' 0[ ]$' > t2 ; diff u t1 t2 | sed -nr 's/^([0-9a-f-])./\1/p' | while read range; do dd status=none if=/proc/1882/mem ibs=4096 skip=$((16#${range//}/4096)) count=$(((16#${range//}16#${range//})/4096)) of=1882-${range}; done zabbix-01:~# xxd 1882-7fc0e09e6000-7fc1098cc000 | wc -l 42919424 zabbix-01:~# xxd 1882-7fc0e09e6000-7fc1098cc000 | grep -Fc '0000 0000 0000 0000 0000 0000 0000 0000' 32186727 zabbix-01:~# xxd 1882-7fc0e09e6000-7fc1098cc000 | grep -Fv '0000 0000 0000 0000 0000 0000 0000 0000' | less
Most of it is empty. And the parts that are neither empty nor gibberish to me (probably some structural data) are either related to SSL encryption or HTML-documents.
ML-KEM-1024 ffdhe4096 ffdhe4096 ffdhe6144 ffdhe6144 ffdhe8192 ffdhe8192 sect163r1 sect163r1 sect193r1 sect193r1 sect193r2 sect193r2 sect239k1 sect239k1 secp160k1 secp160k1 secp160r1 secp160r1 secp160r2 secp160r2 secp192k1 secp192k1 secp192r1 prime192v1 P-192 prime192v1
For testing purposes, I created a HTTP agent item, that shall only get the sites header and return a preprocessing value. There will never be a possibility to reuse the HTTP-Body, as the item is a fixed value from preprocessing. Yet, it seems to remains in memory forever.
Smaller documents seem to be completely intact in memory - headers+body. heise.de is just huge and only parts remain in memory. Therefore I guess, only parts of the HTTP-request are removed from memory. And maybe the remaining small parts are the reason, memory areas are not freed up again.
zabbix-01:~# strings 1882-7fc0e09e6000-7fc1098cc000 | grep heise.de
www.heise.de
J src="https://www.heise.de/assets/ad/adlib.js" event-after-loading="__baCMPReady" needs-consent="true"></a-script><a-script name="Mbmedien" src="/js/ho/mbmedien-reporting.js" [...]ight="heise_plus"><[...]heme-heiseplus" [...]el="Footer schlie
www.heise.de
www.heise.de
[...]
The readable data via `strings` is only 1% of the memory size. But this is the best explanation I can offer.
Is there any known reason for this, a workaround or anybody else, having these issues?
Best Regards
Steffen
