I'm running bacula 5.2.6 under ubuntu 10.04LTS this is a pretty simple setup just backing up the same server that bacula is on as it's the main fileserver.
For some background: The main fileserver array is comprised of 96 2TB drives in a raid-60 (16 raidz2 vdevs of 6 drives per group)). I have a seperate spool directory comprised of 16 2TB drives in a raid-10. All 112 drives are spread across 7 sas HBA's. Bacula's database (running sqlite v3.6.22) is on a SSD mirror. This is going to an LTO4 tape system. The base hardware of this system is a dual cpu X5680 box with 48GB of ram. doing cp, dd, and other tests to the spool directory is fine (getting over 1GB/s), likewise when bacula is running a full backup (10 jobs different directories in parrallel) I'm able to write to the spool directory (vmstat) at well over 700MB/s. btape and dd testing to the tape drive from the spool directory seems to be running fine at 114MB/s which is good. Now when bacula itself does the writing to the tape (normal backup process) I am only getting about 50-80MB/s which is pretty bad. I'm trying to narrow down what may be the slowdown here but am not familiar with the internals that well. My current thinking would be something in the line of: - bacula sd is not doing enough pre-fetching of the spool file? - perhaps when the spool data is being written to tape it needs to update the catalogue at that point? (the database is on a ssd mirror (Crucial C300 series 50% overprovisioned) I do see some write bursts here (200 w/sec range) utilization is still well below 1% (iostat -x)) Doing other testing while bacula is de-spooling to the LTO4 tape I did a DD from the same file going to another array (copy from the spool directory to another un-related drive pool to help gauge available i/o bandwidth and that was well into the 500MB/s range). So this really looks to be something with the despooling process itself. Was looking to see if anyone else has run into similar issues? ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
