Hi,
We are using net-snmp 5.2.4 in an embedded linux envrionment and were
trying to use stash-cache to mitigate some of the known performance issues
with the table iterator. Namely we have a table with 1000 rows and observed
that our get next functions were getting called a ridiculous number of
times during a MIB walk. Basically we hit the n-squared problem discussed
in this link:
http://web.archiveorange.com/archive/v/WnPpShz7hx44EJpP447v
I followed the instructions at this link to insert a stash cache in front
of the table iterator and it worked fine for my first set of test cases
with the net-snmp mib browser:
http://www.net-snmp.org/wiki/index.php/Stash_cache
My code snippet looks like this at the end of my table initialization code:
netsnmp_register_table_iterator(my_handler, iinfo);
/* Inject stash cache ahead of Table Iterator */
netsnmp_inject_handler_before(my_handler,
netsnmp_get_stash_cache_handler(), "table_iterator");
Again this is version 5.2.4.
Basically my first set of test cases just utilized the net-snmp mib browser
to retrieve the table via the table viewer feature. And I was using the
net-snmp mib browser with all of the normal configuration defaults.
It worked great and I saw a tremendous improvement in performance. Exactly
what I was looking for.
However we also have a requirement to also support the *"Poll one row at a
time" *option under the Table View Polling Options in the net-snmp MIB
Browser.
I checked this box and repeated the test with the net-snmp MIB Browser.
This time snmpd crashed and unfortunately it didn't leave me a core dump
file.
*Before Crash:*
root@montavista1:~# ps -ef | grep snmpd
root 5078 4924 0 18:46 pts/1 00:00:00 /usr/local/sbin/snmpd -f
-LE 4 -M/usr/local/share/snmp/mibs
*After Crash:*
root@montavista1:~# ps -ef | grep snmpd
root 5078 4924 0 18:46 pts/1 00:00:00 [snmpd <defunct>]
I instrumented the table iterator code with printfs and verified that
function netsnmp_table_iterator_helper_handler in file table_iterator.c
processed the MODE_GET_STASH command and ran to completion. After that
function returned the crash occurred. So I am guessing it crashed while it
was trying to traverse the cache?
I restarted snmpd and disabled this *"Poll one row at a time" *option and
it worked like a champ.
So I have these questions:
1. What does this Poll one row at a time option do?
2. Has anyone else seen this problem?
3. If so has this problem been fixed in the latest version of net-snmp? (I
don't want to deal with a major upgrade only to find I still have the same
problem.)
4. Is there another way to solve this performance issue with tables?
If I take out the stash cache code my old implementation works fine for
both of my test scenarios described above.
Both scenarios result in a ridiculous number of calls to the get functions.
But when "Poll one row at a time" is invoked it did improve it some; but
not enough.
Regards,
Stan
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
