Hi,
I'm running RHEL 6.2 x86_64 (coming with net-snmp 5.5 branch) where
snmpd is mostly used by HP ProLiant Support Pack components
(hp-snmp-agents).
On one host I've found that snmpd is consuming a lot of memory -
amount of which grows in time. After 24h it runs on ~3GB but I've seen
18GB if deamon has been left running for longer while. What is
interesting is that on other hosts (same RHEL/net-snmp) I can't find
same issue - usually snmpd running with ~300MB of memory for weeks.
So what's special about given host? It's heaving 1700+ network
interfaces up (mostly TUN/TAP). Valgrind confirm there's a leak here:
==2763== 939,072 bytes in 1,608 blocks are definitely lost in loss
record 7,586 of 7,587
==2763== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==2763== by 0x510535F: netsnmp_access_systemstats_entry_create
(systemstats_common.c:170)
==2763== by 0x51072A1: _systemstats_v6_load_ifstats (systemstats_linux.c:649)
==2763== by 0x51082E9:
netsnmp_access_systemstats_container_arch_load
(systemstats_linux.c:678)
==2763== by 0x5106556: netsnmp_access_systemstats_container_load
(systemstats_common.c:106)
==2763== by 0x50E73CA: ipIfStatsTable_container_load
(ipIfStatsTable_data_access.c:316)
==2763== by 0x50E7781: ipIfStatsTable_container_init
(ipIfStatsTable_data_access.c:128)
==2763== by 0x50E6C95: _ipIfStatsTable_initialize_interface
(ipIfStatsTable_interface.c:1341)
==2763== by 0x50E50A1: init_ipIfStatsTable (ipIfStatsTable.c:54)
==2763== by 0x51B8304: init_mib_modules (mib_module_inits.h:23)
==2763== by 0x10BD11: main (snmpd.c:913)
==2763==
==2763== LEAK SUMMARY:
==2763== definitely lost: 939,145 bytes in 1,610 blocks
==2763== indirectly lost: 0 bytes in 0 blocks
==2763== possibly lost: 31,631 bytes in 113 blocks
==2763== still reachable: 6,655,449 bytes in 56,535 blocks
==2763== suppressed: 0 bytes in 0 blocks
There's also a bit of usual complains on NSS/RPM but those are not
,,real'' issues.
I've done a brief run around the code with shotdown_ as a primary
target. Going down function calls there's following:
/**
* @internal
* shutdown the container with functions or wrappers
*/
void
_ipIfStatsTable_container_shutdown(ipIfStatsTable_interface_ctx * if_ctx)
{
DEBUGMSGTL(("internal:ipIfStatsTable:_ipIfStatsTable_container_shutdown",
"called\n"));
ipIfStatsTable_container_shutdown(if_ctx->container);
_container_free(if_ctx->container);
} /* _ipIfStatsTable_container_shutdown */
ipIfStatsTable_container_shutdown() basically is doing nothing ...
well nothing that is interesting from leak point of view.
_container_free() which should free allocated memory must fail
somehow. It's using CONTAINER_CLEAR() with _container_item_free() as a
callback. In general at the bottom we got:
netsnmp_access_systemstats_entry_free(rowreq_ctx->data);
rowreq_ctx->data = NULL;
in ipIfStatsTable_rowreq_ctx_cleanup() that should do the work.
That's all. If you see a clear place where leak happens, a patch would
be welcome. I will try to dig this more.
I can reproduce this with ,,vanilla'' net-snmp-5.5.2.
Cheers,
-Jacek
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
