Simon Fischer writes: > I ran some tests with the 'dbench' benchmark from the samba project which > simulates the disk i/o of the 'netbench' benchmark. > > I use 2.4.16 with the acl-patches (ext2/3) on a 128MB RAM system under zVM > and initially tested dbench simulating 10 clients with ext2, ext3 and > reiserfs on a minidisk. We have a G5(single proc) server connected to our ESS > (shark) with 4 ESCON Channels (...and I think our machine is only lightly > loaded). > > With ext2 I got 20-23 MB/s in several runs and with ext3/reiserfs 10-13 MB/s. > Now I wonder what the bottlenecks are supposed to be and what to do to tune > this before I'll make some further testings?! RAM & CPU seem to be OK for > this workload and I thought 4 ESCONs should be much faster.
Others have already mentioned some of the issues. I'll just add a couple of my own: (1) dbench is an exceptionally poor benchmark in many ways--it not only doesn't measure what it appears to be measuring but working out exactly what it does stress/measure is very difficult. It also is extremely sensitive to random environmental conditions: for example, if the scheduler happens to run the multiple client processes in a batch style then the overall throughput increases hugely (but completely unfairly). (2) One (of the many) potential constraint which might be affecting your case is per-subchannel constraints. Instead of only using one minidisk, try many (16, say, mounted on /vol/0, /vol/1, ..., /vol/f with symlinks from the 128 CLIENTn directories used by dbench to subdirectories of /vol/m allocated round robin). That way, Linux will be able to queue up plenty of requests on each subchannel (though that itself pre-supposes that dbench's behaviour isn't throttling elsewhere depending on things like number of request queue slots and whether I/O throttling in your particular kernel version is done Linus-style on request slots or Alan-style elsewhere :-). It also could easily just push the constraint further up the chain with no gain (but I've definitely got higher figures than your running dbench on a vaguely comparable S/390). --Malcolm -- Malcolm Beattie <[EMAIL PROTECTED]> Linux Technical Consultant IBM EMEA Enterprise Server Group... ...from home, speaking only for myself
