RE: why "snmplib/snmp_alarm.c" needed in net-snmp agent
Mike Ayers
> Sent: Monday, December 07, 2009 10:25 PM
> I was profiling through the net-snmp 5.4.2.1 and found that run_alarms()
> was contributing majorly to the CPU load from the
> "snmplib/snmp_alarm.c" file.
Check your snmpd.conf file. I suspect you've got a lot of monitoring turned on. Many of the monitors: disman, RMON, hardware monitoring, etc. use alarms to schedule their activity, it would seem.
HTH,
Mike
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Net-snmp-users mailing list
Net-snm...@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Dave Shield
> Check your snmpd.conf file. I suspect you've got a lot of
> monitoring turned on. Many of the monitors: disman, RMON,
> hardware monitoring, etc. use alarms to schedule their activity, it would seem.
There are also some MIB modules which rely on re-loading the data
on a regular basis - either to ensure up-to-date information (particularly
if it's relatively timeconsuming to load on demand), or to calculate
rolling average metrics (e.g. various CPU statistics)
Dave
Dave Shield
> But basically there are no other monitoring that is on which can consume
> much of alarm resources.
Please re-read my response.
There are certain MIB modules which *inherently* rely on re-loading
the underlying data on a regular basis, to calculate certain values.
This will inevitably involve the alarm mechanism.
The only way to avoid that would be to omit these modules from the agent.
> My snmpd daemon here is running as a SUb agent and not as masteragent and it
> has only agentx Masteragent's socket defned in conf file nothing else.
Which mudules have you included in your agent?
Mike Ayers
> Attaching call graph of the profiled snmpd daemon.
> Find the graph in attachment.
I think you are misreading this chart. It does show that 81% of runtime is spent inside run_alarms, but 0% of that time is spent on the routine itself. You need to go way down and see that the ifTable and ipAddressTable are using up most of the processing time, which is spent, for the most part, sorting and comparing: array_qsort uses 14% of the time, netsnmp_compare_netsnmp_index 27%, snmp_oid_compare 26%, etc. Nothing surprising here - basically it's. What percentage of your total CPU timeis this using? Perhaps lowering the rate of updates can trim the usage a bit, but I don't know how to do that.
HTH,
Mike
Bart Van Assche
> Attaching call graph of the profiled snmpd daemon.
> Find the graph in attachment.
(replying to an e-mail of two weeks ago)
The call graph is interesting. What you did not yet tell us, and what
is important in order to interpret the call graph correctly, is how
many rows are present on your setup in ipAddressTable.
As you can see in the source code of netsnmp_binary_array_insert(),
this function adds a new entry at the end of the array and sets the
dirty flag. Setting the dirty flag will make the next call of
netsnmp_binary_array_get() (which is called by
netsnmp_binary_array_insert() to check for duplicate entries) sort the
array. It will probably help to modify netsnmp_binary_array_insert()
such that if the dirty flag is not set upon entry, it does not set the
dirty flag upon exit but instead inserts the new entry at the right
position in the array such that it remains sorted.
Bart.
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev