Greg,

We had a similar problem at a customer site.  Although the processing was
not as slow as yours, it was still slow (5 to 10 minutes).  We tried
checking everything within NetView but after about a week, it came down to a
DNS issue effecting the way NetView was resolving names.  You might want to
check to make sure your DNS tables are correct.  Hope this helps.

Scott

Scott Hammons, Senior Consultant
Tivoli Certified Consultant
Advanced Integrated Solutions, Inc.
www.ais-nms.com
Email s.hammons AT ais-nms DOT com
Cellular (210) 378-8229

-----Original Message-----
From: Gregory Adams [mailto:gadams AT us.ibm DOT com]
Sent: Tuesday, July 30, 2002 11:37 AM
To: nv-l AT lists.tivoli DOT com
Subject: [nv-l] trapd processing very slow


Hello
   My environment is:

 NetView 7.1.2
AIX 4.3.3 maint lvl 9

I am seeing a major delay (hours) for traps to get processed by trapd. When
I do a netstat -a | grep trapd I see a constantly high number of messages
in the recv_queue:


tcp4       0      0  *.nvtrapd-             *.*                    LISTEN
70610400 stream      0      0 166c2e80        0        0        0
/usr/OV/socket
s/trapd.socket
7066e400 stream    276      0        0 70614880        0        0
/usr/OV/socket
s/trapd.socket
706a8400 stream      0      0        0 70614640        0        0
/usr/OV/socket
s/trapd.socket
7067ca00 stream  65466      0        0 7007f600        0        0
/usr/OV/socket
s/trapd.socket
706b1a00 stream      0      0        0 7043cbc0        0        0
/usr/OV/socket
s/trapd.socket
706b5800 stream      0      0        0 70765a40        0        0
/usr/OV/socket
s/trapd.socket
7058b600 stream    245      0        0        0        0        0
/usr/OV/socket
s/trapd.socket



In trying to debug this problem I have removed all of my ESE.automation
rulesets in hopes that perhaps
there was something in those rulesets that was causing this problem.
iptrace on port 162 shows the traps have arrived but for example I
generated a test trap and watched the packet appear in the iptrace
after close to 3 hours the trap appeared in the trapd.log and subsequently
2 and a half hours later the trap appeared in the nvevents application.

I have trapd.trace running as well and dont see the application queues ever
exceed what I have them set at, I had increased them from 2000 to 10000
just in case that could be the problem.

Has anyone seen this behaviour or have any ideas ?

Thankyou
   Greg Adams



---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)