hi.... > The best program to spot bottlenecks and have an overview for > the performance of the whole backup process is "amplot". ok, than this will be my way to go. thanks for the tip :-)
> It takes some time to get it running, and study the output, but > it's really worthwhile. from the manpage it 'looks' pretty simple, since amplot has only a few options. what are the caveats? > > > > right now I'm looking at the 'amstatus' of my daily backup job, which > > gives me the following output > > ==================================================== > > Using /var/log/amanda/daily/amdump from Mon Nov 17 08:31:51 CET 2008 > > > > 172.31.2.10:/daten/business 0 11085m dumping 4380m ( 39.52%) > > (8:38:25) > > 172.31.2.10:/daten/company 1 16m finished (8:38:25) > > 172.31.2.10:/daten/intern 0 24001m wait for dumping > > 172.31.2.10:/daten/software 1 242107m wait for dumping > > 172.31.6.10:/daten/blub 0 1623m finished (8:40:33) > > 172.31.6.10:/daten/business 1 0m finished (8:37:14) > > 172.31.6.10:/daten/doku 0 5413m finished (8:45:19) > > > > SUMMARY part real estimated > > size size > > partition : 7 > > estimated : 7 284248m > > flush : 0 0m > > failed : 0 0m ( 0.00%) > > wait for dumping: 2 266108m ( 93.62%) > > dumping to tape : 0 0m ( 0.00%) > > dumping : 1 4380m 11085m ( 39.52%) ( 1.54%) > > dumped : 4 7054m 7054m (100.00%) ( 2.48%) > > wait for writing: 0 0m 0m ( 0.00%) ( 0.00%) > > wait to flush : 0 0m 0m (100.00%) ( 0.00%) > > writing to tape : 0 0m 0m ( 0.00%) ( 0.00%) > > failed to tape : 0 0m 0m ( 0.00%) ( 0.00%) > > taped : 4 7054m 7054m (100.00%) ( 2.48%) > > tape 1 : 4 7054m 7054m ( 3.44%) ERNW-daily02 > > 9 dumpers idle : client-constrained > > taper writing, tapeq: 0 > > network free kps: 248976 > > holding space : 408372m ( 96.12%) > > chunker0 busy : 0:00:00 ( 0.00%) > > chunker1 busy : 0:00:00 ( 0.00%) > > dumper0 busy : 0:05:25 ( 40.25%) > > dumper1 busy : 0:08:04 ( 60.00%) > > taper busy : 0:04:12 ( 31.21%) > > 0 dumpers busy : 0:05:23 ( 40.04%) not-idle: 0:05:23 > > (100.00%) > > 1 dumper busy : 0:03:36 ( 26.79%) client-constrained: 0:02:25 > > ( 67.29%) > > start-wait: 0:01:10 > > ( 32.71%) > > 2 dumpers busy : 0:04:27 ( 33.15%) client-constrained: 0:04:27 > > (100.00%) > > ==================================================== > > Above you say you have 20 clients, but this output shows only 1 client. > is this a test. > You can see that from amstatus that no dumper runs in parallel, because > the default parameters have a restriction of only one dumper per client. > When you have more clients, Amanda will run some dumpers in parallel, > speeding up the whole process. 20 all together. the output above is from my daily backup job, which covers only the data of 2 file servers. all other hosts store less relevant data, so they're backed up only once a week. > > from my understanding amanda is dumping (writing to holding disk) and > > taping (writing from holding disk to virtual tapes) at the same time. > Indeed. > > > Doesn't this reduce speed on the dumper caused by the head-seeks on the > > holding disc? Is there a way to prevent this scenario (as long as the > > holding disc is big enough for all data that belongs to the job)? > > Yes it does reduce the speed indeed. *DAMN* > Optimizing the holdingdisk subsystem is indeed very important for > the newer tapedrives like LTO4 that *need* a sustained feed at 80MB/sec > *at least*, to avoid shoeshining. ok, that doesn't bother me, since I use HD with a virtual tape library to backup my data, and the holding disc is physically another drive than the one storing the data. > Things people often do: > - use a separate controller for disk and tape. > - use a raid striped over several disks as holdingdisk.M > - use large buffers (tapebufs or device_output_buffer_size) > - avoid reading from and writing to the holdingdisk at the same > time (flush-threshold-dumped) ok, I read the amanda.conf(5) man-page on that parameter, but I don't understand what is meant with the term 'volume'. Is it a tape, is it the total amount of data for this backup-job??? please help me clear this. greetz olli
