Hi...

Actually those results looks typical.  Very good in fact.


Your clients are spending all their time looking for files on their
disks to back up.  The client has to scan through the 33,000 files on
the disk, look at the date/time stamps and send them to the server.
The scanning is what takes the time.



Compare the backup times with how long does it take to run

        find / -local -print > /dev/null

(if it is a UNIX system.  Or DIR /S for a Netware/NT/95 system.)



Did you notice that for SHEBA the backup time was 4 minute 40 seconds?
And it only actually transfered 23 files (1 Mbyte).  Therefore the
transfer rate will seem to be small.

Similarly for WATSON you backed up under a 1 MB.  It is interesting
that it scanned twice as many files but took 10 times as long.  This
could be differences in the architecture, speed or loading of the two
machines.




On the ADSM web page there is a performance tuning guide

        http://www.storage.ibm.com/software/adsm/pfguide/tgv31mst.htm

which lists somethings you can try.



From my own experiences with the ADSM server on Solaris:

My server does about 10GB/hour during the backup window.  It has a
100MBit Ethernet connection so that is about the theoertical maximum
[12.5 GB/hour].  I have lots of clients running at once, and each one
takes between minutes and hours to run.


do not put the ADSM database and storage pools on the same physical
disk.  The system will trash the disk moving between accessing the
database and storing files.

I found a significant performance increase when I shifted the
database and disk volumes from files on a file system to using raw
disk space.

Do not define more than one DISK based storage pool volume on a
given physical disk.  If you have multiple clients running, ADSM will
be trying to utilise all the volumes.  With two volumes on the same
disk, you will get trashing.

Similarly, two database volumes on the same physical device will
cause contention.

A log volume and a database volume on the same physical device can
also cause contention.

Keep checking the DB cache utilisation.


And as always, try to observe what is happening before making changes.

what other processes or activity is on the client at the time
any other activity on the ADSM server (sar output, query sessions)
how many concurrent sessions on the server
network load at the time
looking at packet traces for retries and timeouts as a last resort

in roughly that order.

Russell


> Hello
>
> We have Solaris ADSM server v3.1.2 , with the following options in
> dsmserv.opt :
>
> BUFPoolsize 20480
> EXPInterval 24
> MOVEBatchsize 1000
> MOVESizethresh 500
> TCPNodelay yes
> TCPWindowsize 0
> TXNGroupmax 256
> USELARGEbuffer yes
> USELARGETAPEBLOCK yes
>
> The backup is done to disk stg pool. We get bad performance on backing
> up and restore as well. Attach are two of the worst performance during
> the night backup.
> I will appreciate your experience on tunning the ADSM server and
> clients. We get better performance when doing selective/incremental
> backup directly from the client, but still it doesn't get to 1mb/sec.
> Awful !
>
> --------------------------------------------------------------
> SHEBA Total number of objects inspected: 33,977
>
> SHEBA Total number of objects backed up: 23
>
> SHEBA Total number of objects updated: 0
>
> SHEBA Total number of objects rebound: 0
>
> SHEBA Total number of objects deleted: 0
>
> SHEBA Total number of objects failed: 0
>
> SHEBA Total number of bytes transferred: 1.14 MB
>
> SHEBA Data transfer time: 3.43 sec
>
> SHEBA Network data transfer rate: 341.37 KB/sec
>
> SHEBA Aggregate data transfer rate: 4.18 KB/sec
>
> SHEBA Objects compressed by: 0%
>
> SHEBA Elapsed processing time: 00:04:40
> WATSON Total number of objects inspected: 55,937
>
> WATSON Total number of objects backed up: 45
>
> WATSON Total number of objects updated: 0
>
> WATSON Total number of objects rebound: 0
>
> WATSON Total number of objects deleted: 3
>
> WATSON Total number of objects failed: 0
>
> WATSON Total number of bytes transferred: 883.43 KB
>
> WATSON Data transfer time: 0.17 sec
>
> WATSON Network data transfer rate: 5,196.66 KB/sec
>
> WATSON Aggregate data transfer rate: 0.27 KB/sec
>
> WATSON Objects compressed by: 0%
>
> WATSON Elapsed processing time: 00:54:06