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
