>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,
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
Richard Sims, BU