>>>>> "KS" == Kern Sibbald writes: KS> From the statistics you show, the backup does not appear slow to KS> me. The reason you might think it is slow is because you are KS> comparing apples and oranges. KS> On the one hand, you measure the time to to a non-compressed tar KS> on a local machine sending the output down an extremely hi-speed bit bucket. KS> On the other hand, you measure the time of Bacula using KS> compression sending real data to another process via TCP/IP (even KS> though it might be on the same machine). KS> To do a better comparison, you could run tar including the z KS> option so that it does compression. In addition, you should send KS> the output of tar across the network and write it to either a file KS> or a tape (whatever Bacula is using).
You don't seem to have seen my data, so I state it again: bacula backup without SW compression: 1 hour 45 mins 2 secs bacula backup with SW compression: 2 hours 42 mins 11 secs local tar on the fileserver*: 53 mins 3 secs * time /bin/sh -c "tar cf - directory | cat >/dev/null" bacula is ~2 times slower than the local tar without SW compression. And, as stated already, the network isn't the limitation (no TCP retransmission), neither is the backup-server (CPU and disc is >98% idle during backup). But, as you point out, the tar should be faster. It doesn't need to write to net. However, not 2 times faster. The net-load is ~1% (10 Mbit/s on a GE-network), and *should* not affect the performance in this case. KS> At that point, providing you are always doing Full backups on KS> Bacula (and not Incremental of Differential), you will probably KS> find that the total Bacula time is not terribly greater than tar. KS> That said, Bacula will amost always be slower than tar because it KS> does a whole lot more -- in addition to checksuming all the data KS> Bacula writes to the Volume, which I am not sure tar does, Bacula What do you mean bacula is writing to the Volume that tar maybe isn't? KS> also interfaces to a database and stores a lot of information KS> about the job. KS> If you want to do additional performance testing you can look at KS> <bacula-source>/src/version.h. There are various configuration KS> parameters that you can turn on/off and then re-build Bacula and KS> measure the performance of particular parts. Performance testing KS> is a highly evolved science as well as an art, and it is not KS> always easy. For example, if you are going to do any timing KS> experiments as you did, you *must* on Unix systems re-run the test KS> at least 10 times, throw out the first two timings, then take an KS> average of the remaining 8. If you don't do this, your timing KS> tests will have no meaning due to the memory cacheing that Unix KS> does. It is a good general rule in benchmarking to re-run every test several times. And in this case, the fact is that I have, trying to tune the performance of the server. The times were fairly consistent, with an error margin of less than 5 minutes (<10%) in all cases. As the performance difference is in the order of 2 times, I'm quite sure that the results are correct, bacula *is* much slower than tar. I know that I probably should do a lot more testing, but it is very time-consuming... Trying to tune configuration options can be important, do you have any suggestion what can affect this? Are there any known options resulting in bad performance? Thanks for your time. / Anders ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
