On Mon, Nov 26, 2018 at 17:07:54 -0500, Chris Hoogendyk wrote:
> My understanding was that Amanda cannot throttle the throughput, but
> it can see what it is. If it is at or over the limit, it won't start
> another dump. So, you can end up over the limit that you have
> specified for periods of time, but it won't just continue increasing
> without respect for the limit.

To expand on this slightly (and tie it back to the begining of this
thread): what Amanda actually looks at is the dump-size/time figure from
the "info" database it keeps on each DLE.  So, it's not looking at
dynamic real-time network bandwidth usage, but rather calculating what
the average throughput turned out to be the last time this DLE was
dumped.

As you say, the important thing to note is that Amanda uses this info to
do throttling at the dump/dumper level: when there is a free dumper, it
will send a request for a new DLE to that dumper only if the bandwidth
usage calculated for currently-in-progress dumps doesn't exceed the
configured limit.

If the configured limit is too high, the possiblity is that too many
simultaneous dumps, especially of very fast client systems, will
saturate the network interface (or some part of the network
infrastructure) -- while if it's too low, the symptom will be that some
of the configured "inparallel" dumpers will be left idle.  (But the nice
thing about having Amanda do this calculation is that it can go ahead
and kick off more dumpers when working on slow client systems and fewer
when processing the fast ones.)

Anyway, in the case of the original email in this thread, the problem
seems to be that the calculated bandwidth for the single DLE in processs
of being dumped already exceeds the configured bandwidth limit (as
represented by the amstatus report line "network free kps: 0") -- and
thus the other 9 dumpers are all left idle even though there are many
DLEs out there waiting to be dumped.


                                                        Nathan 

----------------------------------------------------------------------------
Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Reply via email to