On Wed, 21 Jul 2004 at 12:00am, Stefan G. Weichinger wrote > Hi, Kris, > > on Dienstag, 20. Juli 2004 at 23:14 you wrote to amanda-users: > > KV> The box is running redhat 9 with 2.4.20 kernel and ext3 filesystem. > KV> Below is the most recent sendsize.debug > > KV> sendsize[27747]: time 11114.784: Total bytes written: 429923983360 (400GB, > 37MB/s) > > ok ... > > KV> sendsize[27747]: time 18815.342: Total bytes written: 69237104640 (64GB, 8.6MB/s) > > not ok ---
Actually, both of those are *very* slow. Remember, those are estimates, and they "write" to /dev/null. When tar does that, it doesn't actually read the bits off the spindles, it just stats the files. On my big (Linux) file servers, I get estimate rates on the order or GB/s -- up to 80GB/s in some cases. One difference, though, is that I'm using XFS. > I would: > > - split venus:/home into several DLEs (via exclude/include) I don't know that this will help. > - exclude unnecessary subdirs/files > (./qa/build-main-branch-rfexamples/rfexamples-20040719/customer_test/Nestoras4/Freq > Domain/Linux_temp-g seems like a candidate to me) That's a good idea, of course. > This would spawn several sendsize-processes in parallel ... Actually, if you look at sendsize*debug, the estimates occur sequentially, not in parallel. ICBW, but that's how it looks to me. Kris, I think that you need to some performance testing/optimizing of your system. What controllers are you using? Have you tested with bonnie++ and/or tiobench? Are there mount parameters to ext3 you can play with (data=writeback comes to mind)? You may also want to spend some time on bugzilla and see if there's some other kernel-foo you can apply to RH's kernel (I assume you're using RH's kernel -- if not vanilla 2.4.20 is awfully old...) to speed up disk stuff. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University