ADSM-L

Re: performance using SCSI disks backuppool

2015-10-04 17:51:03
Subject: Re: performance using SCSI disks backuppool
From: Peter Gathercole [mailto:peter.gathercole AT VIRGIN DOT NET]
To: ADSM-L AT VM.MARIST DOT EDU
I found that ADSM was not able to drive srtiped logical volumes on SSA
(sorry,
not SCSI) disks more than about 4.5MB/s, even though using dd I could get
somthing close to 30MB/s on the same volumes. From this, I concluded that
there
is a bottleneck somewhere inside ADSM, at least at 2.1.5.18.

Peter Gathercole
peter.gathercole AT virgin DOT net

Russell Street wrote:

> 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 ;)
>
> 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
<Prev in Thread] Current Thread [Next in Thread>