nv-l
[Top] [All Lists]

Re: Capacity Planning ....

To: nv-l@lists.tivoli.com
Subject: Re: Capacity Planning ....
From: "Ray Westphal" <westphal@accessus.net>
Date: Mon, 17 Dec 2001 13:59:24 -0600
Thanks Stephen!

Lot's of good stuff here. 

Right now my system seems CPU bound. I thought more CPUs
would be nice to have. Do you have RS6000 model number
recommendations (H80, M80, etc.)?


Ray Westphal.

On Mon, 17 Dec 2001 14:06:08 -0500
 "Stephen Hochstetler" <shochste@us.ibm.com> wrote:
> Ray,
> 
> I have worked with customers with large networks managing
> from AIX.   Some
> tips for you to use as you grow.   This is not inclusive
> of all the
> information that would be in a true capacity planning
> exercise.  Nor is
> this a whitepaper with all the answers.    I am just
> covering some
> important points.
> 
> 1. Will you be expanding operations as well as your
> network?
> - memory on the server is also directly related to how
> many native clients
> (NetView maps) you are running.  Keep that in mind as you
> think about the
> future.   Will you be expanding operations or number of
> operators as the
> network grows.   Will you also be moving them to
> web-based NetView clients
> or leaving them on native clients?
> - base memory for non-native  usage is higher for NetView
> 7.1, but the
> system can then have more web clients once NetView 7.1 is
> installed.
> 
> 
> 2. Will you be CPU constrained?
> - your 4 way should handle the additional interfaces with
> no problem.
> Each NetView process is single threaded, so a 4-way
> machine will let 4
> NetView processes run at once.    You will find netmon,
> ovwdb, trapd to
> usually be the top processes.
> 
> 
> 3. How can I improve my database performance?
> - I think you already have /usr/OV/databases as a
> separate file system.
> Once this starts growing, it will be important to manage
> this a bit closer.
> There are some things you can do to greatly improve
> database processing.
> 
>    The following is quite involved, print this out, read
> it, send me
> questions if you have them.
> 
>   Step 1 - make sure you have a GOOD backup of
> /usr/OV/databases
> 
>   Step 2 - find out the size of the real data in your
> database  files.
> Remember, this data is stored in "sparse" databases which
> means the *.PAG
> files can grow a lot, but the real data will be smaller
> than the file size.
> This is to allow NetView to hash into the file to find
> the data quickly.
> This step will verify that specific files are hashed
> properly for the
> amount of data.   In /usr/OV/service/nvTurboDatabase you
> will find the
> following line:
>     /usr/OV/service/dbmcompress -h o -m 8 -b 3 -o
> /usr/OV/databases/openview/current/value_info
> 
> Do the following command:
>    du -k /usr/OV/databases/openview/current/value_info.pag
> 
> This should give you a value of the actual data, the "-m
> 8" gives you a
> capacity of "8000" from your "du -k" command.    If the
> "du -k" result is
> larger than 8000, then you will want to change the value.
> I suggest you
> copy nvTurboDatabase to something like
> nvTurboDatabase.tuned.     Make all
> your changes in the "tuned" version, this will keep it
> from getting
> replaced by NetView PTFs in the future.     So if your
> "du -k" result was
> 10,000, then I would suggest you change the "-m 8" to a
> larger number like
> "-m 11" or even 12 if you knew your network was
> growing....this is for
> increased performance of larger databases.    Increasing
> this number will
> increase the size of the value_info.pag file when you run
> nvTurboDatabase,
> make sure your filesystem is big enough for this.
> 
> Repeat the commands for /usr/OV/databases/openview/current/obj_info.pag.
> Note the default value is "-m 2".
> Repeat the commands for /usr/OV/databases/openview/current/name.pag.
> Note the default value is "-m 4".
> 
> Read in the documentation about running nvTurboDatabase
> before you run the
> tuned script /usr/OV/service/nvTurboDatabase.tuned.
> 
> 
> 4.   You want to stripe a large /usr/OV/database
> filesystem over a number
> of harddrives.    Once a minute there is a process in AIX
> that dumps to
> disk all cached disk files.   ovwdb caches the database,
> so once a minute
> the database gets written to disk.  While AIX does that,
> it also stops the
> process that owns the cache, now being ovwdb.  Since
> anything that happens
> in NetView need information from ovwdb, it is like AIX
> pausing NetView
> processing once a minute.    To alleviate this, stripe
> the filesystem so
> that AIX can dump it to disk very quickly across multiple
> drives.   In the
> past I have used 100 MB per drive  (600 MB of data on 6
> drives) and found
> the delay to disappear.   Your hardware may give you
> different numbers than
> this.
> 
> 
> 5. There are documented commands that will let you look
> at the netmon
> polling queue to see if it is behind in its polling
> cycle.  You can tune
> the netmon polling and SNMP queue sizes to give netmon
> power to do more at
> once.   It is recommended to increase these queue sizes
> by small
> increments, making it a hugh number may introduce other
> problems.
> 
> 
> 6.  The most common problem for a NetView failure is for
> some sort of
> database corruption.   Since more HA systems share the
> drives it does not
> help you with the most common failure.    Having two
> boxes where the
> NetView database is copied occasionally from one system
> to the backup
> provides a better highly available solution for most
> customers.   It could
> be a nightly copy....or some other appropriate time
> period.
> 
> Kind regards,
> Stephen Hochstetler              shochste@us.ibm.com
> International Technical Support Organization  - Austin
> Office - 512-436-8564                      FAX -
> 512-436-8701
> 
> ITSO redbooks at  http://www.redbooks.ibm.com
> 
> _________________________________________________________________________
> NV-L List information and Archives:


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

Archive operated by Skills 1st Ltd

See also: The NetView Web