-Coders, I've noticed that snmpd/snmptrapd is performing key changes for USM users quite slowly when the overall number of USM users is high. I've done profiling (see http://www.net-snmp.org/wiki/index.php/Debugger#Profiling) to identify the bottleneck. Here's the gprof output for snmptrapd for a test case of ~300 single snmpusm key changes (through the master agent) in a USM user table with ~7600 users:
% cumulative self self total time seconds seconds calls s/call s/call name 61.79 45.50 45.50 21889530 0.00 0.00 usm_generate_OID 29.41 67.16 21.66 7967 0.00 0.00 usm_add_user_to_list 2.78 69.21 2.05 2862 0.00 0.02 var_usmUser 2.19 70.83 1.61 21925643 0.00 0.00 snmp_oid_compare 1.81 72.16 1.33 3180 0.00 0.00 usm_get_user_from_list The usm_add_user_to_list() calls all happen during snmptrapd startup (which takes ~30 sec!). The runtime bottleneck by far is usm_generate_OID(). The snmpv3/usmUser mib module seems to do a linear search through the entire USM user list for every query and constructs the OIDs all over again each time which is killing performance. I realize that snmpv3/usmUser is v4/ucd-based. What are the options for performance improvements? Wes mentioned the possibility to implement an OID cache using the oid_stash functions. However, I'm reluctant to add lots of low-level code to an ucd-based mib module, so what are the other practical options? Suggestions highly appreciated. +Thomas -- Thomas Anders (thomas.anders at blue-cable.de) ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
