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="" 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.