[Top] [All Lists]

Re: [nv-l] Traps Limitation??

To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] Traps Limitation??
From: Gareth Holl <gholl@us.ibm.com>
Date: Tue, 14 Mar 2006 22:21:02 -0500
Delivery-date: Wed, 15 Mar 2006 03:18:45 +0000
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
In-reply-to: <OF1D5AC322.839AC532-ON45257132.00100B0B-45257132.000FD5A6@s-iii.com>
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com

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.


Sent by: owner-nv-l@lists.us.ibm.com

03/14/2006 09:57 PM
Please respond to

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




<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web