Most likely cause of such a thing is a name resolution problem. Each trap
contains at least two addresses for trapd to resolve and if your reverse
lookups aren't working or taking a long time to time out, then traps back
up in trapd, and elsewhere.
I'll wager you have a DNS problem of some kind.
To reduce the negative affects poor DNS operation can have on NetView, the
following parameters in your
"/etc/environment" file are advised:
RES_TIMEOUT=1
RES_RETRY=1
to limit the retries to 1 attempt with a timeout of 1 second.
But I am not sure whether setting them now will get you out of this mess.
You may have to take it all down and lose your queued traps and reboot to
get that to take effect.
Hope this helps
James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group
Gregory Adams/Endicott/IBM@IBMUS
07/30/2002 12:37 PM
To: nv-l@lists.tivoli.com
cc:
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@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.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)
|