What's the queue limit on pending requests?

"Ron Yorgason" <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <[email protected]>
I've written an agentx subagent that gets its data from a database on
another host.  This subagent is supposed to handle requests from 5
different snmp client monitoring stations that are supposed to be
doing gets on roughly 300 MIB attributes, where each client is
supposed to be doing an snmpget on all 300 attributes every second (
*sigh*, don't ask, I can't change this requirement).

Clearly there's a performance issue, that we're hoping will be
addressed by implementing caching on the subagent.  We currently have
one table cached, and we're seeing considerable improvements already
there.

The issue I'm running into is when there are too many requests at
once, I stop getting responses.  We're trying to reduce as much
overhead as possible, so they want each client to do a single get on
all the addresses.  The command line snmpget has a limit of around 127
OIDs, so a C program was written that sends a request through the SNMP
API's with a get request on 280 OIDs at once.

A single client can run fine like this, but once we start 2 clients,
we get a couple successful responses back, but then nothing.  We had
the same issue if we had too many clients using the commandline
snmpget as well.

If I kill snmpd and restart it, after a few seconds the snmp requests
start coming through again. This leads me to guess that the queue
limit is in snmpd, but I don't know for sure.

What I'd really like to know is, is there some hard defined limit on
the number of OIDs that can be requested at once?  Can it be adjusted
by some setting in snmpd.conf or by adjusting some macro in the source
code?  Or is this issue caused by something else?  Am I likely to see
this problem go away once the entire MIB is being cached on the
subagent, rather than dealing with the overhead of communicating with
the database on another host for each request?

Any help would be appreciated,

--Ron

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.