No, I mean you need to take a look at what you are trying to collect,
and if it is not available from the SNMP agent, remove it from your
collections. The only reason it says to increase the timeout is because
it did not get a response to the request. This may not be available from
the agent. In other words, whomever configured the snmp on the device
did not configure it so that you could get those variables(now personally
I would have expected a no-such variable response), but apparently you
are getting no response at all. If you cannot get a response to the variable
you are requesting(this can be checked from the command line), you will
either need to reconfigure snmp on that device to properly respond to the
request that you want, or simply remove the collection for that variable(at
least on that device). In any case, unless you are making requests across
a VERY slow WAN link, a 20 sec timeout is way too much.
Paul
Liu, David wrote:
Paul,
But the error message was saying timeouts is set too small. Do you mean I
have to set it smaller to ignore the "non-reply" collection?
Thanks & regards,
David
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]On
Behalf Of Paul
Sent: Wednesday, January 12, 2005 1:13 PM
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] NV tuning for Data collection
David,
A 20 second timeout may well be part of your problem. If you have
devices that are not responding and so NetView waits 20secs, tries
again, waits 20secs more, then tries again and waits 20secs more.
You have effectively tied up one snmp thread for one minute for data
you know is not coming back. Not an effective use of resources if you
ask me. I would suggest setting the timeout to no more than 5-7 secs.
If you devices are taking longer than that to respond, you have network
issues you should be addressing, not masking them by increasing timeouts.
Paul
Liu, David wrote:
Joe,
Thanks for your reply.
I did turn on the trace and looked at the trace file. The only useful
message was
"hostname doesn't reply to xx(number) object PDU, but responds to
sysUpTime.
Be sure timeouts are not set too small (SNMP interval 20.00s retry:3)."
I have checked the manual, it only says the definition (and the defaults)
but no consequences (or examples).
Regards,
David
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]On
Behalf Of Joe Fernandez
Sent: Wednesday, January 12, 2005 3:28 AM
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] NV tuning for Data collection
David,
I suggest you turn on tracing of snmpCollect with the -T switch if you do
not already have it on, and then look at the trace file snmpCol.trace,
which is in /usr/OV/log. Check what happens as you increase the number of
collection instances.
snmpCollect parameters are documented in the man page which is in
/usr/OV/man/man8. I had a quick look at a Solaris system here and it seems
to me the NetView environment script does not get the path right for the
man pages.
At 08:53 AM 11-01-05 +0000, Liu, David wrote:
Hi list,
I've been reading nv-l archives for quite some times and benefit from
them.
Now I post my first question to get your advice/help.
We are collecting quite a lot data every 15 mins (supposed to), but till
now
only part of the collection happened (everyday less than half i.e. 40
collections per definition per device, sometimes even null). My basic
question is: can NV handle that many collections? Because when I suspended
more than half of the collections (interface data). It seemed working
fine.
If yes, how can I tune the NV? Where can I find the document for the
tuning
(snmpCollect daemon settings)?
Here's some basic info.
NV 7.1.2 on Solaris 2.8.
Data collection of about 600 devices with
1) SysUptime for all of them
2) cpmCPUTotal5min for 400 devices (cisco)
3) ciscoMemoryPoolUsed for 400 devices
4) ciscoMemoryPoolFree for 400 devices
5) ifInUcastPkts, ifOutUcastPkts, ifInErrors, ifOutErrors, ifAdminStatus,
ifOperStatus, ifLastChange, ifInOctets, ifOutOctets, ifInDiscards,
ifOutDiscards, ifInNUcastPkts, ifOutNUcastPkts for about 200 devices with
lot of interfaces
6) Some latency data for 10 routers
Our current snmpCollect (daemon) settings:
Defer time: 60
Max PDU: 50
Config check interval: 1440
Max concurrent SNMP sessions: 50
Verbose trace mode : Yes
Polling interval for nvcold: 60
Thank you in advance.
Regards,
David
Joe Fernandez
Kardinia Software
jfernand@kardinia.com
http://www.kardinia.com
|