ADSM-L

Re: Performance Tuning

1996-06-18 01:12:45
Subject: Re: Performance Tuning
From: "Andrew M. Raibeck" <araibeck AT VNET.IBM DOT COM>
Date: Mon, 17 Jun 1996 22:12:45 PDT
Bryan King queries:

>Has anybody tried modifying the TXNBYTELIMIT and the
>TXNGROUPMAX paramaeters?  If so, how did it work out?

>Also, is anybody using the INCRBYDATE parameter?  How
>much of an improvement has this made?

TXNBYTELIMIT and TXNGROUPMAX: These settings help control the maximum
size of the transactions that are sent to or received from the ADSM
server. TXNBYTELIMIT sets an upper limit on the size of the transaction,
expressed in KB; TXNGROUPMAX sets an upper limit on the number of files
in the transaction. When the transaction is being "built", whichever
limit is reached first will signify the end of the "build" for that
transaction, and said transaction will be sent.

Since there can be significant overhead in transmitting and processing
each transaction, the fewer transactions there are to process, the lower
the overhead; hence, the better the performance (in theory).

Does changing these settings really make a difference? Well, as with
everything else, the answer is "it depends". Generally speaking though,
there is the potential for a dramatic increase in performance, especially
for the following situations:

   - When backing up a lot of small files and/or,
   - When backing up directly to tape.

Prior to the V2 R1 L0.3 client, the default TXNBYTELIMIT was 300 (KB).
Prior to the V2 R1 L0.7 server, the default TXNGROUPMAX was 16 (files).
These defaults have since been increased. The new default values -- and
I may be off on this since this is coming off the top of my head (I don't
have the README files in front of me) -- are 2048 (KB) and 40 (files),
respectively. These should work pretty in a backup-to-disk scenario.

When backing up to tape, you should consider increasing TXNBYTELIMIT to
25600 and TXNGROUPMAX to 256. These are the maximum values. However, I
recommend trying and benchmarking different settings to see which works
best for you.

One caveat: increasing these values may have an effect on the ADSM
server recovery log. The recovery log houses in-flight transactions until
they are committed to the server's database. If you increase the size of
the transactions, you'll increase the amount of recovery log space needed
to house those transactions. So when adjusting these values, I strongly
recommend keeping an eye on the recovery log utilization by periodically
issuing the QUERY LOG command and noting the maximum utilization per
cent value. You may need to add space to the recovery log accordingly.

As far as INCRBYDATE goes: ADSM does not use the archive bit to determine
whether the file has changed. Rather, it examines the file's attributes
such as size, modification date and time, etc., and compares it to those
attributes of the most recent backup version of that file. This means
that for normal incremental backups, ADSM has to query the database for
each file being backed up in order to determine whether that file is a
candidate for incremental backup. This adds some overhead to the backup
process.

INCRBYDATE "short-cuts" that process by only asking the server for the
date and time of the last incremental backup. Thus any changes to the
file that do not affect the modification date and time (such as changing
ownership or permissions) will not qualify that file for an incremental
backup; neither will a new file be qualified for an incremental backup if
it's modification date and time are prior to the date and time of the
last incremental backup.

Therefore, use INCRBYDATE with caution, and be sure to do periodic
full incrementals (i.e. regular incremental backups - not to be
mistaken for "full backups").

Hope this helps,

Andy Raibeck
ADSM Level 2 Support
408-256-0130
<Prev in Thread] Current Thread [Next in Thread>