RE: [nv-l] NetView limitation

2002-08-13 13:33:04
Subject: RE: [nv-l] NetView limitation
From: Abadir Hany-O10544 <hany.abadir AT motorola DOT com>
To: "'Stephen Hochstetler'" <shochste AT us.ibm DOT com>, nv-l AT lists.tivoli DOT com
Date: Tue, 13 Aug 2002 10:33:04 -0700
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 AT motorola DOT com

-----Original Message-----
From: Stephen Hochstetler [mailto:shochste AT us.ibm DOT com]
Sent: Monday, August 12, 2002 4:49 PM
To: nv-l AT lists.tivoli DOT 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
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
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 AT us.ibm DOT 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 AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT com

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>