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
arno@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 AT lists.sourceforge DOT 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
