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 [EMAIL PROTECTED] Computer Systems Support (v) 518 486-1697 Wadsworth Center (f) 518 473-6384 NYS Department of Health Help Desk 518 473-0773