Hello Gene, Paul, Stefan, Jon and Amanda users,
I wanted to give my thanks and close the issue of dumping
concurrancy and thought I could do it publicly in case I
needed to find it again.
Please know that this is my understanding and may not be a fully
accurate technical description, I tend to screw up the jargon and
its been over a week... My apologies if I've left anyone out or
screwed up your excellent advice.
This particular case study was for a server with itself as the
single client. OS is Solaris 5.8, Amanda 2.4.2p2. The issue was
needlessly complicated by our moving the amanda.conf file forward
from older versions of amanda and not configuring a new amanda.conf
with its new features/switches during previous amanda upgrades.
We were seeing that the amanda run was taking a large amount
(aproaching 12 hours) of wall clock time and 'guessed' based
on the amdump report that the partitions where dumping sequentially,
at least the two larger partitions where.
It was rather silly to guess as there is a tool what would have
helped me, "amplot" will plot holding disk, bandwidth and dumper
utilization as a function of time. I have to admit I'd never used
this tool before and it would have told me where my problem was
right away. Well worth a proactive look by all amanda admins.
First pass at a fix was to increase the size of the /amanda/work
area as the largest partition occupied most of it (even after rather
good compression). This did not reduce dump time.
The next step was to verify that I wasn't having issues because of
spindle number in the disklist file. I was not, the default (leaving
the field blank) causes scheduling based on spindle access to be ignored.
Obviously not making any changes to this parameter did nothing to
improve performance.
The next step was to check amanda.conf and verify the "inparallel" value.
This was set to 4, actually equal to the number of DLEs. This was not
the reason backups where taking so long.
At this point I should also report that while two of the partitions
where very large (this box is a Lotus Notes server) two of the
partitions where fairly small (used for OS). There was ample room on
the work disk to backup a small partition with the largest partition
or two small partitions with the 2nd largest.
It was at this point that I was asked what my "maxdumps" parameter
was set to. Probably this is something that would have been obvious
in a newer version of the amanda.conf file, my version didn't list
this parameter at all. The default is "1".
"inparallel" is the maximum number of dumpers that can run in parallel
on the server.
"maxdumps" is the maximum number of dumpers that can run in parallel
on a specific client.
Setting maxdumps to anything greater than 1 would have helped...
This would have been obvious if I'd checked the amplot output.
However, this didn't decrease run time either.
At this point we discovered "netusage" was set to a very low value
(1200 though I'm uncertain of the units). This parameter, if exceeded
will prevent "additional" dumpers from initiating. It allowed one to
start but prevented a second one from starting.
Note 1 on this, I was surprised that with server = client this was
a factor.
Note 2, this would have been obvious in the amplot output.
Note 3, this was available as text information in the amdump.1
log file. This is in the directory pointed to by the "infolog"
variable in my amanda.conf file (actually one level up from that,
just above the curinfo/ directory).
We increased the value of netusage and nightly run time halved. Given
that are dumping lots of Gigabytes the dump time is reasonable and
we are certainly completing before the start of the new work day.
Much thanks to Paul Bijnens, Jon LaBadie, Gene Heskett and
Stefan G. Weichinger for their time and efforts in helping me to
resolve this issue.
thank you,
Brian
---
Brian R Cuttler brian.cuttler AT wadsworth DOT org
Computer Systems Support (v) 518 486-1697
Wadsworth Center (f) 518 473-6384
NYS Department of Health Help Desk 518 473-0773
|
