Re: [nv-l] Traps Limitation??
2006-03-14 22:18:45
There is always going to be a limit
of some sort, whether with the hardware, OS, or trapd's ability itself.
This is most likely dependent on the resources (CPU speed, number of CPUs,
and available memory per process) available on the system hosting NetView.
trapd may end up consuming most, if
not all cycles of a single CPU during heavy trap reception. So a multi-CPU
box would be essential so that other processes could continue to run. High
CPU utilization caused by trap floods and even the subsequent processing
of the traps by other daemons such as nvcorrd could well affect netmon's
ability to keep up if it cannot get the CPU cycles it needs.
trapd will try caching/queuing all events
received (with the goal to eventually process every single one of them),
hence the need for a large amount of memory and an adequate queue size.
The cached events will be processed when there is a break in trap reception.....this
could be some time after the trap was originally generated. So while trapd
is still receiving traps, it is possible for NetView's internal events
(including those from netmon) to be caught up in this process and thus
stayed queued/unprocessed for some time. This probably isn't a direct affect
on netmon but instead more of a perceived affect as status events are not
processed in a timely fashion and thus nodes don't change color on the
map in a timely fashion
That's all I have.
Gareth
usman.taokeer AT s-iii DOT com
Sent by: owner-nv-l AT lists.us.ibm DOT com
03/14/2006 09:57 PM
|
To
| nv-l AT lists.us.ibm DOT com
|
cc
|
|
Subject
| [nv-l] Traps Limitation?? |
|
Hi List,
Just wanted to know are there any limitations On Netview on the number
of traps (coming from different nodes) it can handle? If there is any would
it effect the behaviour of netmon?
Regards,
Usman
Si3.
|
|
|