Amanda-Users

Re: statistics

2002-09-04 19:20:50
Subject: Re: statistics
From: Jay Lessert <jayl AT accelerant DOT net>
To: greg <greg AT z-axis DOT com>, amanda-users AT amanda DOT org
Date: Wed, 4 Sep 2002 16:03:38 -0700
On Thu, Sep 05, 2002 at 03:29:39PM -0700, greg wrote:
> Does this look right?
> 
> STATISTICS:
>                           Total       Full      Daily
>                         --------   --------   --------
> Estimate Time (hrs:min)    0:06
> Run Time (hrs:min)        11:48
> Dump Time (hrs:min)       11:42      11:42       0:01
> Output Size (meg)       24171.4    24171.4        0.0
> Original Size (meg)     54320.4    54318.3        2.1
> Avg Compressed Size (%)    44.5       44.5        1.5   (level:#disks ...)
> Filesystems Dumped            3          2          1   (1:1)
> Avg Dump Rate (k/s)       587.4      588.0        0.8
> 
> Tape Time (hrs:min)       11:41      11:41       0:00
> Tape Size (meg)         24171.5    24171.5        0.1
> Tape Used (%)              64.5       64.5        0.0   (level:#disks ...)
> Filesystems Taped             3          2          1   (1:1)
> Avg Tp Write Rate (k/s)   588.5      588.5       29.3
> 
> 
> It is saying it took 11 hrs to dump 54GB or 24GB compressed.  I have
> a quantum DLT8000-40 which is rated at 6MB/s or 12MB/s compressed.
> 11hrs seems a long time even considering gzip as the software
> compression.  Is there something I am missing here?

It would be useful to see the "DUMP SUMMARY:" section, but the average
dump and tape rates *almost* match, so it looks very much like your two
full dumps were straight to tape, did not use holding disk, and were
rate-limited by gzip.

There are other things that could have limited the dump rate, but
gzip is the first place to look.  You can force fulls on the
same two file systems and run a top in background, something
like:

    % top b -d300 -n500 > top.out &

...on the client(s) and server in question, see how much cpu time the
gzip processes take.  If the gzip times are short, then I would
try running the backup processes (dump or tar or whatever) by
hand to /dev/null and see how long that takes.

-- 
Jay Lessert                               jay_lessert AT accelerant DOT net
Accelerant Networks Inc.                       (voice)1.503.439.3461
Beaverton OR, USA                                (fax)1.503.466.9472

<Prev in Thread] Current Thread [Next in Thread>