Hi Kern,
On Saturday, September 13, 2014 08:34:47 AM Kern Sibbald wrote:
> Hello,
>
> The AveBytes/sec is the total number of bytes read from the FD for that
> job divided by the total number of seconds the job has been running.
>
> The LastBytes/sec is the number of bytes read from the FD for that job
> since the last status command using a trivial smoothing algorithm that
> includes the prior value of LastBytes. Note, if you use multiple status
> commands the LastBytes/sec will be updated if you wait at least 10
> seconds between status commands.
>
> Part of the calculation is done with 32 bit integer arithmetic, so there
> is a possibility that there is a truncation error once the TotalBytes
> exceed 4 billion -- i.e. there may be a bug in the calculation that I
> will look at.
>
> If you can check to see if the calculations look good during the first 4
> GB of backup, but then drop to zero, please open a bug report.
Some clarifications and corrections after further investigation:
Those zero transfer rates are reported only for the jobs despooling to tape;
jobs spooling to disk (spooling=1) report correct rates regardless of the
total amount of bytes transferred (checked for up to 1+ TB)
CORRECTION: Reports for fobs doing despooling to tape also get their Files and
Bytes reported values stuck (not incremented, unlike I wrote previously).
Hence it makes sense that their speed rates get zero readings as well. This is
all true for status reports displayed under "Running Jobs" close to the top of
the "status sd" output.
HOWEVER: At the same time, status report output under Device below (for my 2
tape drives) displays constantly incrementing values. So the tape drives are
actually engaged and despooling is progressing but the "Running Jobs" section
does not reflect this.
The reason I am trying to figure out all these speed-related details in the SD
status report is that ever since after the upgrade to 7.0.5 my despooling to
tape speeds are extremely slow: down to about 0.7 - 2 M Bytes/sec. Previously,
with the Bacula v2.4.4 Director/SD/FD, it was routinely at 15 - 20 M
Bytes/sec.
My hardware is two Sony SDX-1100 (AIT5) drives (SCSI) in a Qualstar RLS-4445
autochanger.
This issue looks very similar to the following (now closed) bug:
http://bugs.bacula.org/view.php?id=1973
--Ivan
> On 09/13/2014 04:49 AM, Ivan Adzhubey wrote:
> > Hi all,
> >
> > I have recently upgraded to Bacula 7.0.5 on my old backup server, which
> > seems to have worked fine. However, I am now trying to figure out how to
> > interpret rather detailed status messages produced by various "status"
> > command. One particular puzzling thing is the following Storage status
> > line:
> >
> > *status sd
> >
> > xxxx-sd Version: 7.0.5 (28 July 2014) i686-pc-linux-gnu ubuntu 8.04
> > Daemon started 12-Sep-14 01:21. Jobs: run=2, running=2.
> >
> > <...>
> >
> > Running Jobs:
> > Writing: Full Backup job XXXX JobId=52618 Volume="LF0033"
> >
> > pool="LargeFull" device="Drive-1" (/dev/nst1)
> > spooling=0 despooling=1 despool_wait=0
> > Files=292,872 Bytes=63,980,083,815 AveBytes/sec=0 LastBytes/sec=0
> > FDReadSeqNo=3,388,503 in_msg=2576431 out_msg=9 fd=19
> >
> > The strange part is that the "AveBytes/sec" and "LastBytes/sec" values are
> > always zero while at the same both Files and Bytes counters keep
> > incrementing. The job seems to be busy despooling and making progress but
> > the speed-o-meter readings are not reflecting this.
> >
> > Is this a known problem?
> >
> > Thanks,
> > Ivan
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
