Kai Zimmer wrote:
Run Time (hrs:min) 110:57
Dump Time (hrs:min) 120:52
Sorry, i didn't completely understand that. Run time can't be lower
than dump time, so parallelizing will gain max. 10h ?
Yes it runtime should be much lower than dumptime when having
many clients.
From my "archive" run this weekend:
STATISTICS:
Total Full Daily
-------- -------- --------
Estimate Time (hrs:min) 0:39
Run Time (hrs:min) 12:07
Dump Time (hrs:min) 51:45 51:45 0:00
This means that the backup was done in about 12 hours, which would
have taken more than 4 times as much when doing every DLE sequentially.
Amanda does dump many clients at the same time.
About your problem, the pdf shows that from the 16 dumpers you started,
only a minority is busy: a peak of 40% in the beginning, and then only
1 or even 0 dumpers for a long time.
At the same time the holdingdisk is used 100%.
Together it means that your holdingdisk area is too small.
If possible I would add a cheap large disk in the server (200 Gbyte
or more would be nice). You can configure multiple holdingdisks.
The graph also shows the tapedrive is (almost) always busy. That's
good. You can fill the little gap with having a larger holdingdisk.
The total data was 716188 Mbyte and took almost 110:57 - 8:56 = 102:01.
That is 1996 kB/sec.
You didn't specify what tapedrive and host server you used, but this
seems a little low to me. What is the expected throughput of your
tapedrive (what does amtapetype indicate as speed)?
My tapedrive is a simple AIT-1 drive, 35 Gbyte native capacity,
theoretically doing 3MBytes/sec. Amanda does 2600 kB/sec on
average (large partitions going at 3000-3090 kB/sec). And the
amanda server is only a 300 MHz Celeron with 128 MB RAM and a 80
Gbyte IDE holdingdisk.
Slow tapespeed can be the result of one or more DLE's bypassing
the holdingdisk. That results in the tapedrive not streaming anymore.
The file "amdump.1" contains the keyword "PORT-DUMP" instead of
"FILE-DUMP" for such partitions. Are there any?
Again adding holdingdisk space would help in that case (or splitting
those DLE's into smaller ones).
Having a large holdingdisk, and many parallel dumpers, could result
in doing the dumps fast, finishing before people come in and load
the client machines, and taping all those collected images can then
proceed at the normal tapespeed, but without bothering the end users.
--
Paul Bijnens, Xplanation Tel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512
http://www.xplanation.com/ email: Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************
|
