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 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
