Hello...

It has been my experience that ADSM can drive the storage pool disks
to 100% busy.  And do it efficiently, that is not having them seeking
all over the surface.  That should be >2GB/hour.

Assuming you are on a UNIX system:

Have you examined the output of 'sar' (or equiv) to see what your SCSI
disks are doing?  Are they 100% busy?  Wait times?



I also found early on that changing from volumes on file systems to
raw disk for the storage pools made a huge difference to the
throughput.

With an even bigger performance win for the database and log volumes.


On AIX JFS could be causing the ADSM data to be put on the disk twice
--- once into the journal, then again into the file system.  An AIX
expert could confirm or deny this ;)
expert could confirm or deny this ;)



You did not say what type of data is coming in.

If it is small files then check the "Cache Hit Pct" line of "query db
f=d".  The list has done this one to death in recent weeks.

You could also try turning off caching on your storage pool.  This way
ADSM will not have to constantly delete cached files for the new data.
I did not see much performance difference with caching on or off.


For large files ADSM tends to stream the data onto the disk.  But with
a twist: it will not stripe incoming files across volumes in a storage
pool.  One incoming file goes to one volume.


As a last resort: you could try deleteing the disk from ADSM, creating
a file system on the disk and seeing what rates you can get from the
OS itself.


Russell




>         We are using SCSI disks for primary storage pool( backuppool). This
> gives roughly about 2Gb/hr per node. whether I run this concurrently or in
> isolation does'nt seem to alter the performance by too much. Is there any
> scope for any improvement?. How much performance would be acceptable for a
> server with SCSI disks as the backup storage pool?
>
> My cpu is I/O bound.
>
>
> Thanks
>
> Sri