Thanks for all the replies....
The Original Question Was:
> The DBA folks are asking for some kind of
> performance
> analysis for one of our servers on which they are
> experiencing performance problems. They want to
> upgrade the server (more memory, more CPUs better
> storage etc)... They are asking for some kind of
> documentation from the sysadmin standpoint that
> would
> justify this.
>
> Any ideas of what I could give them??
I got an overwhelming amount of responses on this one.
Most suggest using various performance mangement
tools...The most popular being "Collect"..
Others suggestions included:
VMUBC
pmgr
The ultimate performance analysis and capacity
planning tool for TRU64
unix and NT is called "PAWS" from Compaq. - Lyndon
Handy
BigBrother (
http://bb4.com)
and the "larrd" extention (
http://www.deadcat.net) and
you managers will be able to look at system
performance graphs on an HTML web page anytime they'd
like, without having to bother you. - Jim Fitzmaurice
alan_at_nabeth.cxo.dec.com gave the following summary
which I though was very accurate:
Performance monitors are almost as plentiful as
custom
versions of ls(1)... The base system has iostat and
vmstat for looking at I/O request and data rates, and
basic memory activity and CPU stats. The program
Monitor on the Freeware (or Open Source) CDROM and
gatekeeper.dec.com:/pub/DEC/monitor.alpha.tar.Z
combines these and some network statistics in a
single
display. It can also save the data to a file for
later analysis and includes a variety of sample
analysis
programs.
Collect is probably also on the Freeware CDROM and
may
included in the base system on some recent versions.
It
collects much the same data as Monitor, but draws
much
better graphs. If per-process CPU and memory
utiliziation
seem interesting top can provide this information.
There are also performance monitoring products that
you
have to pay to use or at least have to pay to use all
the features of them. Look at the products available
on the Associated Products CDROM.
Overall CPU time gets accounted for as one five types
of
time; user mode, kernel mode, nice mode (user mode
with
an increased "nice" value, wait time and idle time.
Many
of the programs combine user mode and nice time.
Some
combine wait time and either kernel time or idle
time.
An interesting measure of CPU utilization is the load
average which is simply a running average calculated
over different time spans of the number runnable
processes.
Oversimplified, each "1" value of the load average is
the number of CPUs that could potentially be kept
busy
in a system.
On the memory side, the easiest thing to look at is
the
amount of free memory. It may not be the best thing
to
look at, but it is the easiest. Tru64 UNIX supports
a
Unified Buffer Cache that allows the file system
buffer
cache to use all of available memory. With a
sufficient
file system I/O load on a system, memory not being
used
by processes will used by the cache. If the cached
data
is mostly read data, getting it back for processes is
very cheap and fast. On the other hand, if it is
mostly
dirty (written to cache, but not disk), it fairly
expensive
to free up for processes. The point, is that a low
value
of "free" memory may not really indicate whether the
system
is short of memory.
A look at the paging stats may be a better
indication. If
pages have to be written out to page/swap space, then
it
suggests that there is a steady short fall.
If your load does include a steady file system I/O
load,
then more memory can often help since it allows more
data
to be cached.
I/O loads are hardest to measure. Vendors typically
quote
their device burst rate, which is nearly always the
maximum
bus speed. If they quote request rates, they don't
offer a
clue how long the service time is to support that
rate. If
your load interactive waiting for the database to
respond
then response time may be more important than the
request
rate. Looking at the I/O rates may offer some hint
that
the I/O load is not well distributed among the
available
I/O adapters.
Finally, performance characteristics are rarely
absolute.
A system where all the CPU time is being used, can
still
be quite responsive as the time is sliced up among
the
various processes that use it. A system with little
free
memory may simply have paged out all the data that
doesn't
get used much and the remainder is used for buffer
cache
to avoid file system I/O. An I/O load may seem high,
but
could have plenty of head room to keep response time
down.
Workloads often to be measured within the context of
how
the system is used. You need to be able to compare
the
performance of the system when it is acceptable with
the
performance when it isn't.
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
Received on Tue May 29 2001 - 17:21:11 NZST