ADSM-L

Re: Performance/striping/etc.

1998-09-04 17:30:08
Subject: Re: Performance/striping/etc.
From: Peter Gathercole <peter.gathercole AT VIRGIN DOT NET>
Date: Fri, 4 Sep 1998 22:30:08 +0100
Paul Hilchey wrote:

> On Sep 3,  6:52am, Bruce Elrick wrote:
> > Given AIX 4.2.1 or higher on an RS/6000 with SSA disk, would the
> > following be a reasonable disk allocation policy for performance and
> > reliability?  I put my comments after each.  I welcome other comments as
> > well.
> >
> > 1) Use ADSM mirroring for database and recovery log with mirrorwrite set
> > to sequential for both
> > - Yes, protection from corruption is the highest goal.
> >
> > 2) Raw logical volumes for all disk volumes (db, log, & stgpool)
> > - JFS adds journaling but only for FS structure changes (inode
> > allocation, directory structure changes) and thus prvides marginal
> > protection.  The primary advantage of JFS is over other non-journaled
> > FS's, protecting you from the need to do long fsck's after crashes.
> > - Raw LV's waste some space ((PP size - 1MB) for db and log, but this is
> > acceptible)
> > - JFS adds a (small?) performance hit on top of the LVM overhead.
> > - Does JFS add any performance gains via read-ahead and caching that
> > aren't realized by raw LV AND are actually useful given the way ADSM
> > accesses the volumes (the buffpool and logpool show that the db and log
> > is doing its own optimization for disk access)
>
> If you mirror your disk storage pool volumes, you want to use JFS.
> Using AIX mirroring with a raw logical volume is bad because you
> will clobber the mirror synchronization data that is kept in the
> first bit of the logical volume.
>
> > 3) Use AIX low level striping (software RAID 1) where volume size
> > permits
> > - I know I can 'dd' (sequential read & write) to SSA striped at close to
> > 35 MB/s vs what 7-9 MB/s for single disk access; does this benifit ADSM
> > given its access patterns?
> > - alternately, does one give one volume to each spindle and let ADSM's
> > spreading of load across multiple volumes do the trick?
>
> If you are not mirroring your disk storage pool volumes, you want one
> volume per spindle.  That way you don't lose as much if you lose a disk.
>
> Striping is designed to maximize your sequential I/O bandwidth.  It
> can give you a substantial performance penalty with random I/O by
> spoiling the locality of reference that the application or filesystem
> may provide.  For ADSM, I would be cautious with low-level striping
> unless more information was available to base a decision on.

I'm not sure I agree about the mirror synchronisation being clobbered. I think
that the mirror synchronisation is contained on the outer edge of the physical
volume, not the logical volume itself. I do not believe that anything you
write to the logical volume can damage the mirror synchronisation.

On the subject of performance, the stripe size vs the unit of data that is
commonly written is the determining factor for performance. Ideally, you
should make the strip size equal or less than the unit of data you write.This
should give you the maximum bandwidth whether you are writing in a sequential
or random manner. Of course, there are the normal overheads on random I/O on
top of this.

I am not sure about how ADSM allocates space in random access (disk) volumes
in storage pools, but for the data that we write (mainly large files), I would
expect that the data is written in a largely sequential manner.

One thing that I noticed when doing some tests is that when I had four disks
set up as four volumes in a storage pool, with co-location turned off, files
were written in rotation between the volumes. Is this because only one ADSM
session can write to a random access volume at any time (I'm not talking at an
instant, but within the process scheduling cycle of the operating system). If
this is the case, then having a single large striped volume would cause access
bottlenecks if multiple clients were performing backups, and one session had
to wait for another to release the volume. Can anybody clarify this. This
would have an impact on our scheduling of backup sessions.

Peter Gathercole
Open Systems Consultant
<Prev in Thread] Current Thread [Next in Thread>