Re: net-snmp-5.4.2.1 snmpd cpu usage 100%

Hello Wes Hardaker,

Thanks very much for your valuable inputs here.
We are starting the snmpd with -f option, so i guess i am going right there.

I am attaching a sample gpofile output file to your refrence generated from
my HW environnment.
May be this can give better data for investigations.

I will get back on the remaining questions.
But as an observation for cache->timeout, it is being used for
ifTable_initialization, but not for ipAddressTable_initialization.
So cache-> flags are only being used commonly.

Let me know.

Thanks very much.

BR,
Bheemesh




On Thu, Nov 19, 2009 at 7:10 AM, Wes Hardaker <
[email protected]> wrote:

>
> bv> Has anybody done so far profiling with gprof or any equivalent tool
> bv> for src code profiling for net-snmp-5.4.2.1 or any prev versions?
> bv> So far we are finding it tough to generate the gmon.out file for
> bv> profiling data generation.
>
> I have, but it's been a while.  In the past I successfully used gprof to
> profile various aspects of the agent.
>
> bv> We have seen reasons being the start directory, multi threaded programs
> bv> unsuitable for profiling etc.
>
> We don't use multithreading.  Do make sure you run the agent with -f
> though.
>
> bv> Also so far for this mail chain, no one has given any leads, is it
> because
> bv> my question is ambiguos or do i have to give bit more background of
> info
> bv> regarding our system setup?
>
> Actually, I think you've done a really nice job explaining your
> problem (much better than our average user).  Unfortunately, your
> problem is also fairly complex which makes it hard to answer quickly
> (and a large number of developers got very busy with other aspects of
> their life and jobs all at the same time).
>
> > netsnmp_arch_interface_container_load() function from
> > "if-mib/data_access/interface_linux.c" has a file pointer to
> "proc/net/dev"
> > from it tries to get updates of each interface in a while loop, which
> takes
> > too much of cpu time when we have many VLAN interfaces defind in our
> server
> > this loads CPU 100%.
>
> There are a few things I can think of:
>
> 1) the code in question isn't well optimized for 4000 vlans and takes a
>   long time to load.  I'm actually not sure, but I'd think it would
>   actually be ok.
> 2) make sure the code is supporting caching.  With 4000 entries in the
>   /proc/net/dev file you *don't* want to re-read it frequently.
> 3) Is it possible that parsing is failing?  IE, is it possible there is
>   a bug in the code that is preventing the function from ever quitting?
>   Does the CPU stay at 100% forever or does it eventually drop back down?
> 4) You should try running a *single* snmpgetnext on the iftable with the
>   following options: "-r 0 -t 600", which will make snmpgetnext wait
>   for a long time and only try once.  See if you ever get a response.
>   If you do, rerun the command *immediately* (and hopefully the next
>   request will return more quickly if it's cached).
>
> If it takes too long to fill the cache because of that many entries, you
> may want to increase the caching time for that particular code.
> --
> Wes Hardaker
> Cobham Analytic Solutions
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

_______________________________________________
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