Laurie,
Thanks for the input. I
have carried out the changes but still I cannot get the graphs of the interfaces.
The snmpCol.lrf file was saying 0 of 5 concurrent SNMP requests and now it says
0 of 50. I would appreciate any other help.
Regards,
Ioannis
-----Original
Message-----
From: owner-nv-l@lists.us.ibm.com
[mailto:owner-nv-l@lists.us.ibm.com] On
Behalf Of Laurie.Gellatly@netic.com
Sent: Friday,
April 30, 2004 2:06
PM
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] graph and
daemon problems
I think you need to change the
snmpCol.lrf to have more concurrent collections.
and then view
/usr/OV/log/snmpCol.trace.
You'll probably see a line near the
end of the file like
1 of 5 concurrent SNMP requests in
use
I'd suggest you can happily increase
that concurrent setting to say 50 would be OK.
Edit /usr/OV/lrf/snmpCol.lrf and
change it from :
OVs_YES_START:nvsecd,trapd,ovwdb,ovtopmd::OVs_WELL_BEHAVED:120:
OVs_YES_START:nvsecd,trapd,ovwdb,ovtopmd:-n
50:OVs_WELL_BEHAVED:120:
and again view /usr/OV/log/snmpCol.trace,
where you should see a later line like:
1 of 50 concurrent SNMP requests in use
It adds more network and CPU load to
your server, but it allows the collections to be completed in a shorter time.
Most of the time is spent waiting
for the responses anyway!
HTH
...Laurie :{)
OverTime: MRTG/RRDtool from within NetView
----- Original Message -----
Sent: Thursday,
April 29, 2004 11:25 PM
Subject: RE: [nv-l]
graph and daemon problems
It's hard to imagine what might be wrong since you are
so far downlevel. Lots of maintenance has been delivered since then, and
as I said, I am not expert in this area. I don't work on data collection
nor graphing.
My
only suggestion is that if you have lots and lots of data then you might go
into /usr/OV/app-defaults/Xnm and increase you maxMallocPoints from the default
of 5120 to something much greater, say four times that amount.
But
the real answer may lie in what happens when you try to graph. Do you get
an error message when you try to graph or what?
Other
than this, I have no suggestions. I am hoping that some other user who
does graphing all the time will have some suggestions. Because if not,
you will have to open a problem to Support.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
|
"Ioannis Yerou"
<ioannisi@ieee.org>
Sent
by: owner-nv-l@lists.us.ibm.com
04/29/2004 07:31 AM
|
|
To
|
<nv-l@lists.us.ibm.com>
|
|
cc
|
|
|
Subject
|
RE: [nv-l] graph and daemon problems
|
|
James,
Thanks a lot for the input. First, I checked for the ovwdb
and you were right. The number in cache was 10000 and the objects number was
12000. Therefore, I changed the number to 15000. Now, regarding the graph I
changed the collection time to 10 min but still it does not seem to work. What
I have noticed in the log is maybe what you are calling gaps. For many routers
it says is not up.
Any other input regarding the graph problem will be
appreciated.
We are planning to upgrade the version of Netview to the
latest.
Thanks again,
Regards,
Ioannis
-----Original
Message-----
From: owner-nv-l@lists.us.ibm.com
[mailto:owner-nv-l@lists.us.ibm.com] On
Behalf Of James Shanks
Sent: Wednesday, April 28, 2004 4:16 PM
To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l] graph and daemon problems
OVs_NON_WELL_BEHAVED is not an error condition but an indication that these
daemons can stay up independently of the core daemons like ovwdb, pmd, and
trapd. The ones you cite will always be OVs_NON_WELL_BEHAVED, as will
others like nvpagerd.
You high ovwdb CPU rate on the other hand is not good. Is your cache size
properly adjusted? Do "ovobjprint -S" and see what you object
count is. Then make certain that your cache size on ovwdb is at least 20%
greater. Otherwise the daemon will spend a lot of time allocating and
reallocating storage to hold your object database in memory.
And you really should plan to move to a supported level of the code.
7.1.1 has not been supported ever since 7.1.3 came out over two years
ago. The current maintenance level on 7.1.3 is FixPack2, which means that
you are 5 version of the code downlevel so far. FixPack3 for 7.1.3 is in
the works now.
But none of these things has anything to do with your problem. graphing
is done by xnmgraph on data collected by snmpCollect.
I am not an expert in this area but I do know that data will not graph if there
are gaps in the data, and I'll bet that if you look in the snmpCollect log you
will find lots of errors, producing those gaps. Collections get deferred
if an error occurs, which produces those gaps. Offhand, I would guess
that you cannot successfully poll 200 routers for data in 3 minutes. If
you quadruple the number of devices to collect from, I'd suspect you have
to more than quadruple the collection interval.
Anybody else?
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
|
"Ioannis Yerou"
<ioannisi@ieee.org>
Sent by: owner-nv-l@lists.us.ibm.com
04/28/2004 08:11 AM
|
|
To
|
<nv-l@lists.us.ibm.com>
|
|
cc
|
|
|
Subject
|
RE: [nv-l] graph and deamon problems
|
|
Hi to all,
It has been some days now that the grapher stopped to display the
BandwidthUtilIn and BandwidthUtilOut (from MIB Data Collection) for the
interfaces of the routers selected. Even though I can see that the data is
collected for all the routers. I have changed the time interval from 1 min to 3
min but no effect. I should also mention that I was collecting data for about
50 routers without problems and the last month that number was increased to
200. I noticed also the following things which I don’t know if they are
related. Two deamons trapgend and mgragentd even though running are
OVs_NON_WELL_BEHAVED. The last thing is that the process running the ovwdb
takes about 99 to 100% of CPU continuously.
Any Ideas?
Netview 7.1.1
AIX 4.3
ARN Nortel Routers
Regards,
Ioannis