2013/1/15 Jacek Luczak <difrost.ker...@gmail.com>:
> 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.
I've tracked down this issue - a bit but always sth :)
Navigate to bug entry for details: https://sourceforge.net/p/net-snmp/bugs/2437/
Shortly on affected host agent shutdown is never called thus we leave
all memory allocated for container data.
-Jacek
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
