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.
I receive similar values also with other "block size".
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
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
---------------------------------------------------------------------------------
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
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
---------------------------------------------------------------------------------
Can it be I should search the mistake with the controller SCSI?
I use an Adaptec 29160 controllers with the standard settings.
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?
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
|
