>How do I know how many dumpers are active?  ...

Amanda will start the number you tell it to.  The real question is,
how well are they being used.  The easiest way to tell is with amstatus.
In particular, running it against a completed amdump.<nn> file.

For instance, I have this as part of my "run-amanda" script right
after amdump (the syntax may be different at 2.4.1p1 -- I forget):

  amstatus ${config} --summary --file amdump.1

Since the most recent amdump.<nn> file is always amdump.1, this gives
me a summary of what happened during this run.

Part of the output looks like this (although I just noticed it's broken
with 2.4.2 -- sigh :-):

  ...
  dumper0 busy   :  5:52:01  ( 98.03%)
  dumper1 busy   :  0:23:09  (  6.45%)
  dumper2 busy   :  0:13:27  (  3.75%)
  dumper3 busy   :  0:16:13  (  4.52%)
  dumper4 busy   :  0:06:40  (  1.86%)
  dumper5 busy   :  0:03:39  (  1.02%)
    taper busy   :  3:54:20  ( 65.26%)
  0 dumpers busy :  0:03:21  (  0.93%)   file-too-large:  0:03:21  (100.00%)
  1 dumper busy  :  4:03:22  ( 67.78%)     no-diskspace:  3:40:55  ( 90.77%)
                                         file-too-large:  0:21:13  (  8.72%)
                                           no-bandwidth:  0:01:13  (  0.50%)
  2 dumpers busy :  0:17:33  (  4.89%)     no-bandwidth:  0:17:33  (100.00%)
  3 dumpers busy :  0:07:42  (  2.14%)     no-bandwidth:  0:07:42  (100.00%)
  4 dumpers busy :  0:02:05  (  0.58%)     no-bandwidth:  0:02:05  (100.00%)
  5 dumpers busy :  0:00:40  (  0.19%)     no-bandwidth:  0:00:40  (100.00%)
  6 dumpers busy :  0:03:33  (  0.99%)         not-idle:  0:01:53  ( 53.10%)
                                             no-dumpers:  0:01:40  ( 46.90%)

  This says:

    dumper 0 was busy almost all the time

    dumper 1 (and above) were not used very much

    taper was busy about 2/3 of the total run time

    all dumpers were idle less than 1% of the total run time

    one dumper was busy 67.78% of the total run time and the reason two
    dumpers were not started when one was busy was not enough holding
    disk space (no-diskspace) 90.77% of that time, the next image to
    dump was too large to fit in the holding disk at all (file-too-large)
    8.72% of that time and network bandwidth was exhausted (no-bandwidth)
    0.50% of that time
  
BTW, the above is straight out of the book chapter.

>...  It said both dumpers
>were active, but there were no dumper processes on the one client box
>in my disklist file.

The dumper process only runs on the server, not the client.  Each dumper
is responsible for reaching out to one client and backing up one "disk".

What, exactly were you trying to do?  If you were trying to increase
the number of dumps that go on at once on a single client, you need to
increase maxdumps.  If you need more dumpers because clients are "starved"
for service, then increase inparallel.

>Robert

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

Reply via email to