On Thu, Dec 24, 2009 at 1:28 PM, bheemesh v wrote:
> On Thu, Dec 24, 2009 at 2:53 PM, Bart Van Assche > wrote:
>
>> On Fri, Dec 11, 2009 at 11:20 AM, bheemesh v wrote:
>> > Attaching call graph of the profiled snmpd daemon.
>> > Find the graph in attachment.
>>
>> (replying to an e-mail of two
HI Bart,
Thanks very much for your inputs.
In fact we have 500+ IP's configured on this machine.
Meanwhile as a optimization i tried was to avoid the
netsnmp_binary_array_get() call from "netsnmp_binary_array_insert()", so
that sort will be called only when the last entry in the container is bein
On Fri, Dec 11, 2009 at 11:20 AM, bheemesh v wrote:
> 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 grap
HI,
Thanks Mike for notifying this part.
But i have a more generic question now on the logic of updating the MIB
entries (such as IF-MIB, IP-MIB etc) to NMS:
There are 2 triggers for updates done to the NMS:
1) Whenever a new network configuration is done, will there be a trigger to
update the C
> From: bheemesh v [mailto:bheem...@gmail.com]
> Sent: Friday, December 11, 2009 2:20 AM
> 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 tha
2009/12/11 bheemesh v :
> 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 wi
Hello Mike & Dave,
Thanks for your inputs here.
But basically there are no other monitoring that is on which can consume
much of alarm resources.
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.
For
2009/12/8 Mike Ayers :
> 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
> From: bheemesh v [mailto:bheem...@gmail.com]
> 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 y
