nv-l
[Top] [All Lists]

RE: [nv-l] NetView limitation

To: "'Stephen Hochstetler'" <shochste@us.ibm.com>, nv-l@lists.tivoli.com
Subject: RE: [nv-l] NetView limitation
From: Abadir Hany-O10544 <hany.abadir@motorola.com>
Date: Tue, 13 Aug 2002 10:33:04 -0700
Stephen
Thanks for all the information you provided

I ran the command ovobjprint | wc -l  and the result was  114216
then by a quick calculation which is not necessary correct but to give me a 
round figure
to reach the 200,000 objects I'm looking for about 2100 systems total

                Hany Abadir
                Motorola, Inc.
                IT Systems Engineer
                GIS - Enterprise Systems Management
                Tel: (480) 441-3036
                e-mail: hany.abadir@motorola.com
                http://gis.mot.com/ebusiness



-----Original Message-----
From: Stephen Hochstetler [mailto:shochste@us.ibm.com]
Sent: Monday, August 12, 2002 4:49 PM
To: nv-l@lists.tivoli.com
Subject: RE: [nv-l] NetView limitation



That is why I said it is tricky to talk about NetView limitations.   Really
you can identify bottlenecks that your particular configuration is having.
A person with experience can suggest resolutions to your bottleneck.

You have unmanaged all but one interface per system.  Where does this help?
1. It helps the traffic on the interface card
2  It reduces the CPU load of the netmon process  (polling)

Where does this not help?
1. Unsolicited traps -- trapd process
2. Memory used by ovwdb   -- managed or not, they take the same memory in
database
3. Memory taken by the open maps
4. netmon configuration checking, still reads data for managed and
unmanaged interfaces.
5. snmpcollections (if you have them configured)
6 ....etc

You can have bottlenecks on a NetView server that also always has
solutions.  The solution may be tuning, configuration or hardware.
1.  Interface card traffic.   (tune your AIX settings)
2.  Can netmon keep up with all polling.  (can be CPU bound, queue sizes,
adjusting timeouts, adjusting retries)
3.  trap storms kill your processors  (put in MLM, configure as trap
filter)
4.  ovwdb slow  (verify cache size is 120%)
5. cpu bound  (put a local DNS on NV server, load DNS with EVERY interface
in your network)
6.  cpu bound (everything else done, move from a 1-way to a 2-way or 4-way
hardware box)
7.  In AIX, database cache writes affect operators, pause every minute
(strip database filesystem over multiple drives)
8.  .... this list could go on for a while.

Kind regards,
Stephen Hochstetler              shochste@us.ibm.com
International Technical Support Organization  - Austin
Office - 512-436-8564                      FAX - 512-436-9326

ITSO redbooks at  http://www.redbooks.ibm.com



---------------------------------------------------------------------
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)

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web