ADSM-L

Re: Pointers for optimizing backup performance

1996-04-24 18:11:35
Subject: Re: Pointers for optimizing backup performance
From: Paul Zarnowski <VKM AT CORNELLC.CIT.CORNELL DOT EDU>
Date: Wed, 24 Apr 1996 18:11:35 EDT
On Wed, 24 Apr 1996 15:14:44 -0400 Joe Morris said:
>We're still testing this stuff out and I'm certainly not a point of
>performance tuning.  However, I'm confused on what type of ideal settings
>to use.  I just have the basic staging pool on magnetic disk with the tape
>pool next in line.  The magneteic storage area is only 8Mb.  What are the
>ideal migration settings for that storage pool to get a smooth flow of
>data going to tape (8mm for right now)?  Larger pool?  Very low migration
>threshholds?  Not sure what is best here.

Joe,

I'm certainly not an expert on this either, but I can tell you what we
have tried, and why.  We also have been using a 2-drive 8mm robot.  Our
strategy was to allow a full night's worth of backups go to disk, without
requiring any tape mounts (except for huge files).  We have a 10GB disk
staging area, and we back up about 3-4GB per night.  So, we set the
lo-water migration threshold to 60% during the day, at about noon, and
the hi-water mark to 65%.  This always triggers a migration at about noon.
At 7AM, we trigger an Inventory expiration, using the new admin schedule
facility in v2.  This usually (but not always) completes by noon.  The
idea here is that we want to avoid migrating any files to tape that we
are about to expire.  So we expire them first.  This is an attempt to
make our tape use a bit more efficient.  As our tape robot has filled up,
this has become more of an issue, because it becomes harder to keep free
space in your tape storage pool (you have to keep doing reclaims to free
up tape space).  Thankfully, we just decided to acquire a 2nd robot, so
we won't have these problems again for quite awhile.  But I digress.

After the migration completes, sometime in the afternoon, the reclaim
threshold is lowered.  Finally, just before nightly backups start up,
the hi and lo-water marks for migration, and the reclaim threshold, are
both raised again.  The goal here is to try to avoid doing more than one
of the following activities at the same time:

nightly backups
expiration
migration
reclaim

These >seem< to run much more efficiently if you only have 1 of these
running at the same time.  We found that if any of these ran at the same
time as "nightly backups", that the nightly backups sometimes ran very
long, into the daytime working hours.  Not a disaster, but something to
be avoided if possible.

To summarize:

7AM:  Expire Inventory
12:   MigHi=65, MigLo=60                (frees up 4GB for nightly backups)
3PM:  Reclaim=60 (or whatever you like)
9PM:  Reclaim=100, MigHi=95, MigLo=90   (discourage DB-intensive processes)
      Backups start

One benefit of having extra disk capacity in your disk storage pool,
is that if you have enough of it, more files will expire while they are
still on disk.  We find that some files change daily.  We keep 2 extra
versions of files around, by default.  So, if we can keep these files
on disk for 3 days, they are likely to expire before they get moved to
tape.  Unfortunately, we have no good way of identifying what these files
might be.  It would be really nice to see which files are getting expired
every day.

Of course, another more obvious benefit to having extra disk is that
file recoveries can often be done much more quickly.

Another reason that you don't want to back up directly to tape, is that
you probably won't be able to feed data to the tape drive quickly enough
to keep it from going into start/stop mode.  When 8mm drives go into
start/stop mode, it adds to head and tape wear, which is a big concern
with 8mm technology (IMHO).  In fact, even though we do almost all of
our 8mm tape writing via migration, I think our tapes still go into
start/stop mode a bunch.  I believe this is because ADSM cannot update
its database quickly enough to keep the 8mm drives fed at the rate they
can accept data.  This is a real problem for us, and if anyone has ideas
on how to improve database performance (on an AIX server), I'd like to
hear them.

I think I've probably rambled too much.
..Paul

Paul Zarnowski                     Phone:   607/255-4757
Cornell Information Technologies   Fax:     607/255-6523
Cornell University                 US Mail: 315 CCC, Ithaca, NY 14853-2601
<Prev in Thread] Current Thread [Next in Thread>