Hello,

03.12.2009 07:08, Jens Froehlich wrote:
> Arno Lehmann schrieb:
>> ...
>>
>> Looks all very good.
>>
>> I would try dd'ing some random data to tape next.
>>
>> Running sar or, at least, vmstat and top during testing and a slow 
>> backup might reveal some unexpected bottlenecks.
>>
>> Also, it's important to see where the backups are slow - for example, 
>> the actual data transfer can be fast, and the catalog operations slow. 
>> You can see some of that in the job report mail. (That wouldn't be too 
>> uncommon, as catalog operations can vary in speed quite a lot, 
>> depending on which database you use, and how that database is tuned.)
> 
> 
> Hello Arno,
> 
> I has news. My problems are not possibly to be searched with bacula.

Erm... I understand that as "the problem is not inside Bacula", right?

> I receive similar values also with other "block size".

Ok. That at least makes things easier.

> It, however, is still unclear to me where the cause can lie.
> Blind to company?
> 
> 
> Storage is quick enough.
> 
> bacula:/data # dd if=/data/testfile_urandom  of=/dev/null bs=1M count=100000
> 10000+0 Datensätze ein
> 10000+0 Datensätze aus
> 10485760000 Bytes (10 GB) kopiert, 55,5439 s, 189 MB/s

That looks good.


> vmstat
> 
> procs -----------memory---------- ---swap-- -----io---- -system--
> ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy
> id wa
>  2  0 2252924 122632   4780 3842528    0    0 181172    50 1942 3412  0
>  9 73 18
>  1  0 2252924 123600   4944 3841136    0    0 178092    10 1921 3361  0
>  9 76 15
>  2  0 2252924 121876   5120 3842712    0    0 180784     0 1878 3376  0
>  9 75 16
>  1  1 2252924 120496   5292 3843956    0    0 167332    12 1757 3170  0
>  9 76 16
>  0  1 2252924 122408   5464 3841696    0    0 177324     0 1856 3385  0
>  8 74 17
>  0  1 2252924 122568   5640 3841608    0    0 180016     0 1900 3338  0
> 10 74 16
>  0  1 2252924 121100   5820 3842700    0    0 180660     8 1909 3384  0
> 10 72 18
>  0  1 2252924 121620   5996 3841924    0    0 178608     0 1891 3375  0
> 10 74 16
> ---------------------------------------------------------------------------------

That doesn't look very good - the IOwait is too high IMO. Here I get:

> dd if=/tmp/MSOffice2010ProfessionalPlusBETA.exe bs=1M of=/dev/null &
[1] 2218
a...@neuelf:~/bacula_repo/trunk/bacula/src> vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- 
----cpu----
...
  1  1 373456  16216   5252 1305196    0    0 37796     0 1021 2297  1 
  7 49 43
  1  2 373456  16888   5304 1306436    0    0 35692   100  863 2157  0 
  5 46 49
  1  1 373456  15624   5332 1309168    0    0 31872   110 1045 1803  2 
  7 45 47
  2  0 373456  16952   5356 1309976    0    0 33876    17 1424 1909  0 
  9 27 64
  1  1 373456  16784   5368 1312028    0    0 39720     0  915 2066  0 
  8 50 42
  1  1 373456  16020   5408 1314908    0    0 43144     0  920 1930  0 
  9 50 42
  1  1 373456  16268   5408 1316460    0    0 33624    84  780 1752  0 
14 41 45
  0  1 373456  16888   5344 1317120    0    0 36256   132  838 1650  0 
  7 49 44
  0  1 373456  15540   5368 1320392    0    0 33296     0 1000 1743  0 
  6 42 52
  1  1 373456  16564   5380 1321836    0    0 39412     0  881 1858  0 
  7 48 44
  0  1 373456  15336   5392 1324972    0    0 37668     0  871 1834  0 
  8 48 44
...
749+1 Datensätze ein
749+1 Datensätze aus
786299944 Bytes (786 MB) kopiert, 22,5493 s, 34,9 MB/s

So, while a lower throughput in general (but the file is on the only 
RAID array I use, so other processes on this machine affect it), I see 
much less IOwait.

> Here the problem
> 
> bacula:/data # dd if=/data/testfile_urandom  of=/dev/nst0 bs=1M count=1000
> 1000+0 Datensätze ein
> 1000+0 Datensätze aus
> 1048576000 Bytes (1,0 GB) kopiert, 185,538 s, 5,7 MB/s

Definitely very slow.

> vmstat:
> 
> procs -----------memory---------- ---swap-- -----io---- -system--
> ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy
> id wa
>  0  0 2252924 121308   8640 3839784    0    0  6148     0  153  205  0
> 0 99  1
>  0  0 2252924 121208   8652 3839924    0    0  5124    12  131  218  0
> 1 98  2
>  0  0 2252924 120144   8660 3841028    0    0  6152     0  128  176  0
> 0 99  1
>  0  0 2252924 121096   8664 3839844    0    0  5124     8  172  206  0
> 2 97  1
>  0  0 2252924 121136   8668 3839924    0    0  5124     0  116  164  0
> 1 98  1
>  0  0 2252924 121140   8676 3839988    0    0  5128    12  150  173  0
> 1 98  1
>  0  0 2252924 124000   8688 3837056    0    0  7172    48  233  282  0
> 1 96  3
>  0  0 2252924 123852   8704 3837152    0    0  5128    52  214  258  0
> 1 97  3
> ---------------------------------------------------------------------------------

Looks like it's limited by CPU, as the IOwait is nearly 100%.

> 
> Can it be I should search the mistake with the controller SCSI?
> I use an Adaptec 29160 controllers with the standard settings.

Possible, though I don't know. The results somehow look like the SCSI 
subsystem doesn't work very well. I haven't checked recently, but 
there might be options available to the kernel module you use... which 
one is it?

> scsi 0:0:4:0: Sequential-Access HP       Ultrium 1-SCSI   E32U PQ: 0 ANSI: 3
> scsi target0:0:4: Beginning Domain Validation
> scsi target0:0:4: wide asynchronous
> scsi target0:0:4: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 15)
> scsi target0:0:4: Domain Validation skipping write tests
> scsi target0:0:4: Ending Domain Validation
> 
> 
> Do you have one more idea?

The SCSI bus seems to work with 80 MB/s, which should get you more 
than the few MB/s throughput you observe. As long as there's no 
indication of problems in the system logs, I can only suggest to check 
if the module responsible for the HBA can be tuned...

Arno

> 
> Jens
> 
> 
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing. 
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
> 

-- 
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
www.its-lehmann.de

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to