ADSM-L

Re: performance considerations

2001-05-08 07:53:33
Subject: Re: performance considerations
From: Richard Sims <rbs AT BU DOT EDU>
Date: Tue, 8 May 2001 07:54:23 -0400
>I've been trying to optimize the network throughput, but without real
>luck. Then I tried backing up the tsm server through lo0 and I ended up
>with the following result
>
>Total number of objects inspected:   49,295
>Total number of objects backed up:   49,295
>Total number of objects updated:          0
>Total number of objects rebound:          0
>Total number of objects deleted:          0
>Total number of objects expired:          0
>Total number of objects failed:           0
>Total number of bytes transferred:     2.45 GB
>Data transfer time:                  546.68 sec
>Network data transfer rate:        4,706.32 KB/sec
>Aggregate data transfer rate:      2,041.05 KB/sec
>Objects compressed by:                    0%
>Elapsed processing time:           00:03:00

Henrik - Using lo0 was a smart approach to gauging performance, in
         eliminating real network time.  Some observations...

Your test was backing up a large number of files of roughly 52 KB each,
if my math is correct.  This is the "many small files" thing, which
involves a lot of database processing, which is where the tuning
attention must be concentrated.  Here are the usual considerations in
that area, which I've compiled into QuickFacts:

Database performance                    - Locate the database on disks which are
                                          separate from other operating system
                                          services, and choose fast disks and
                                          connection methods (like Ultra SCSI).
                                        - Spread over multiple physical volumes
                                          (disks) rather than consolidating on a
                                          single large volume: TSM gives a
                                          process thread to each volume, so
                                          performance can improve through
                                          parallelism. And, of course, you
                                          always benefit by having more disk
                                          arms to access data.
                                        - Do 'Query DB F=D' and look at the
                                          Cache Hit Pct. The value should be up
                                          around 98%. If less, consider boosting
                                          the server BUFPoolsize option.
                                        - Assure that the server system has
                                          plenty of real memory so as to avoid
                                          paging in serving database needs.

In general, to deal with "many small files" you need a fast server system
processor, plenty of memory so as to maximize having DB pages in real memory, 
and
fast disk, distributed over I/O pathing.

If your test is indicative of your configuration doing daily backups where
the client and server are in the same system, consider changing to the
Shared Memory COMMmethod to boost performance somewhat.

To gauge the performance of your I/O throughput and essentially eliminate the
TSM db as a factor, consider a test where you back up one or more very large
(1 GB or more) files.

>Does anyone know of a new tivoli performance tuning guide? I have a (not
>up to date) SP performance tuning guide.

The assemblage has been awaiting such a modern version of the product
performance guide.

   Richard Sims, BU
<Prev in Thread] Current Thread [Next in Thread>