>>>>> "BM" == Bill Moran <[EMAIL PROTECTED]> writes:
BM> In response to "Anders Boström" <[EMAIL PROTECTED]>: >> >>>>> "BM" == Bill Moran <[EMAIL PROTECTED]> writes: >> BM> In response to "Anders Boström" <[EMAIL PROTECTED]>: >> >> >> gzip on this computer, on one CPU, reach about 18 Mbyte/s. bacula with >> >> >> gzip only reach ~7.7 Mbyte/s. This leads me to believe that there are >> >> >> room for improvement. >> >> BM> Again, the story changes. Above, you indicate that tar+gzip ran about BM> 15% faster than bacula with gzip, which seems reasonable. Now you're BM> saying that gzip is ~twice as fast as Bacula + gzip. Where did this new BM> number come from? Are you taking in to account networking on this new BM> test? >> >> >> >> If I state that "gzip on this computer, on one CPU, reach about 18 >> >> Mbyte/s", I mean just that, nothing else. To clarify, this means that >> >> pure gzip-performance on this computer, using just one gzip-process, >> >> is 18 Mbyte/s. >> BM> If you would be kind enough to humor me ... >> BM> Please create a file (or use an existing one) of notable size: few BM> hundred meg. >> BM> Put the file on the disk and time gzipping it. Run it 5 times. >> BM> Create a memory filesystem and repeate the gzip tests with the BM> file living on the mfs and the gzipped target existing on the mfs. >> BM> I have a suspicion that your drives are the limiting factor in this. BM> The above tests should confirm or deny that theory. >> >> I've already done this, but did it again. The results are the same, >> disc and tmpfs gives the same results, about 18 Mbyte/s. And I would >> have been *very* surprised if they had differed, as the disc-tests >> are running out of memory in test 2-5 (due to caching). BM> If the system is caching the entire write operation in RAM, then you're BM> set up for a major disaster some day. I know that we might loose some data if we have a server crash or hardware failure. However, it is not a "major disaster". Turning off disc write-cache, mount ext3 sync, sync NFS-export and turning off NFS-client-cache isn't an option, performance is just too low. BM> Even if there's enough RAM to cache the read op, the write op will BM> ALWAYS require disk writes. If those two operations are taking the BM> same amount of time, then either you're testing wrong, or something BM> is really weird with your setup, or you have the fastest hard drives BM> on this planet. I agree that it is slower to write to disc, *but* as the write-performance to disc is less than 9 Mbyte/s (>50% compression rate), the difference might be hard to measure. Our discs sustain >60Mbyte/s and provided efficient DMA to disc, the slowdown might not be significant. BM> Additionally, the point was to _not_ allow it to use cache for the disk BM> ops, which I didn't communicate clearly -- my apologies. OK, I will not test this, as it is a production file-server. I can't turn off all disc-caching without scheduling a service-window, and frankly, I don't see the point in this test. What are you trying to test? Why? / Anders ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
