Re: [nv-l] Traps Limitation??

[Gareth Holl <gholl@us.ibm.com>]

Would require a thorough study of your
environment before I could properly advise. Performance problems always
do. A job for the NetView Support team. 

Try reducing polling timeouts. Try reducing
the number of retries. Try increasing the polling period and see if you
see improvements (regardless of whether you want to keep the new changes).

Can you absolutely guarantee that you
don't have DNS performance problems. More often than not, DNS operation
contributes to problems, if not being the primary cause.


Gareth

usman.taokeer@s-iii.com
Sent by: owner-nv-l@lists.us.ibm.com

03/15/2006 09:47 AM

Please respond to
nv-l

To	nv-l@lists.us.ibm.com
cc	nv-l@lists.us.ibm.com, owner-nv-l@lists.us.ibm.com
Subject	Re: [nv-l] Traps Limitation??

Gareth, 

Ok! here is the scenario: 

NetView 7.1.4 FP04 
Windows 2003 SP1 
Hosted on a Dell Dual XEON Processor with 2GB RAM!

There are around 1200 Nodes discovered in the network, and we have around
400 Routers which are sending different traps to the Netview server. The
problem is whenever we try to "Demand Poll, Quick Test etc" any
device it just keeps saying "Waiting for netmon to respond" !!!
Any clues what's causing this? There is plenty of Memory available and
the CPU utilization is also between 4-10% only! 


Regards, 

Usman Taokeer 
Si3.

Gareth Holl <gholl@us.ibm.com>
Sent by: owner-nv-l@lists.us.ibm.com

15-03-06 08:21 AM

Please respond to
nv-l@lists.us.ibm.com

To	nv-l@lists.us.ibm.com
cc
Subject	Re: [nv-l] Traps Limitation??

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@s-iii.com
Sent by: owner-nv-l@lists.us.ibm.com

03/14/2006 09:57 PM

Please respond to
nv-l

To	nv-l@lists.us.ibm.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.