Re: What's the queue limit on pending requests?

Ok, so maybe I was off in my theory as to the problem.  I'm trying to
determine what timeouts are affecting my performance, and how to
adjust them to get what I need.

I ran some tests, using pstack to monitor activity in my subagent
process.  I have a C program that continually creates a pdu containing
280 OIDs and then makes the request using snmp_synch_response().

Now, you'd think that a single client making synchronous requests
wouldn't ever get backlogged.  It makes a request, waits for a
response, and then sends the next one.  But I get about 5 successful
replies, each one comes a little slower than the last one before I
start seeing timeout errors.  I can stop my snmp client from making
requests, but based on the output from pstack, the subagent is still
running for several more seconds.

The only reason I can think of this getting backlogged is if the
subagent is still processing a request when snmpd times out and
reissues the request.  The subagent finishes processing the original
request, sends the response, and now it has to deal with the duplicate
response.  In the meantime, the client is already making another
request which will also likely not finish in time, so another
duplicate request is made.

If I put a one second delay between when the client gets a response
and when it issues another one, this backlog does not happen and it
can continue to process requests indefinately.  Unfortunately, this is
not acceptable due to customer requirements :(

So, this is my theory, I'm looking for verification that this is in
fact what happens, and how I can adjust the timeouts.  Adjusting the
agentXTimeout in snmpd.conf didn't prevent this snowballing problem.

I just found where I can adjust the session timeout/retries values
which are currently being set to the default -1 by snmp_sess_init(),
but I'm not sure this is the timeout I'm looking for.

--Ron

On 9/5/07, Ron Yorgason <[email protected]> wrote:
> 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