Two things. First the easy one. OVs_NON_WELL_BEHAVED status is nothing to
be concerned about. It just means that these daemons will not go away even
if their predecessors do, unlike ovtopmd for example, which will stop if
traps does. This is a permanent condition and reflects how the daemons is
designed and not an error. I believe this is explained in the Diagnosis
Guide.
Second, non-zero queues in netstat means a busy, busy process. There are
things queued up for him to handle, which means he is working as hard as he
can in your environment, and is still somewhat behind. The only way to
tell what is going on is to trace the daemon's activities, which for
nvcorrd is done with the nvcdebug command. Type "nvcdebug -d all" and then
you can watch nvcorrd log what he is doing to /usr/OV/log/nvcorrd.alog and
blog. Every thousand lines of output, the active log will switch from the
alog to the blog and back again. If you stop and restart the daemon, the
contents of the alog are moved to the blog and he starts logging in the
alog first. In the log you can see what traps are being processed and
how long it takes. Look for the eyecatcher "Received a trap" and
"finished with the trap". Everything in between is nvcorrd processing that
one trap. You can use the timestamps as a rough approximation about how
long it takes and perhaps see where the bottlenecks lie. And you can
compare the timestamp of the event in trapd.log versus the finished with
the trap timestamp for the same trap in nvcorrd to see whether, and how
far, behind nvcorrd is.
You can always contact Support if you want help with this.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
"Gavin Newman" <NEWMANGJ@banksa.com.au>@tkg.com on 04/10/2001 07:18:41 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: <nv-l@tkg.com>
cc:
Subject: [NV-L] nvcorrd - query on netstat
Hi
There have been a number of mentions in this list about the send & recv
queue figures for nvcorrd on a netstat -a display.
Since my AIX 4.3.3 production system was rebooted out from under Netview by
an IBM tech for hardware maintenance I have noticed that the netstat -a
display shows non-zero values for nvcorrd and a partner socket. These
values vary from time to time but never reach zero.
I also note that an ovstatus display shows that the trapgend & mgragentd
daemons report OVs_NON_WELL_BEHAVED status - this may be a red herring as
this is also the case on my development Netview system which was not
rebooted and on which the nvcorrd netstat report showes zero length on the
queues.
The rule processing seems to be a bit flaky but it is also the case that
the production Netview box is handling a large number of traps in addition
to the normal network events.
Is this high queue length on nvcorrd a sign of a problem (in which case
where do I look?) or just a sign of a very busy box (in which case how do I
tell how close it is to choking to death?)
Cheers - Gavin
**********************************************************************
***** IMPORTANT INFORMATION *****
This document should be read only by those persons to whom
it is addressed and its content is not intended for use by
any other persons. If you have received this message in
error, please notify us immediately. Please also destroy and
delete the message from your computer. Any unauthorised form
of reproduction of this message is strictly prohibited.
Bank SA is not liable for the proper and complete transmission
of the information contained in this communication, nor for any
delay in its receipt.
**********************************************************************
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|