quoted

I happen to be the friend Maurice was talking about. I let the raid

layer keep

quoted

its default chunk size of 64K. The smaller size (below like 2MB) tests

in

quoted

iozone are very very slow. I recently tried disabling readahead,

Acoustic

quoted

Management, and played with the io scheduler and all any of it has done

is

quoted

make the sequential access slower and has barely touched the smaller

sized

quoted

random access test results. Even with the 64K iozone test random

read/write is

quoted

only in the 7 and 11MB/s range.

It just seems too low to me.

I don't think so; can you try a similar test on single drives not using
md RAID-5?

The killer is seeks, which is what random I/O uses lots of; with a 10ms
seek time you're only going to get ~100 seeks/second and if you're only
reading 512 bytes after each seek you're only going to get ~500
kbytes/second. Bigger block sizes will show higher throughput, but
you'll still only get ~100 seeks/second.

Clearly when you're doing this over 4 drives you can have ~400
seeks/second but that's still limiting you to ~400 reads/second for
smallish block sizes.

	John is perfectly correct, although of course a 10ms seek is a
fairly slow one.  The point is, it is drive dependent, and there may not be
much one can do about it at the software layer.  That said, you might try a
different scheduler, as the seek order can make a difference.  Drives with
larger caches may help some, although the increase in performance with
larger cache sizes diminishes rapidly beyond a certain point.  As one would
infer from John's post, increasing the number of drives in the array will
help a lot, since increasing the number of drives raises the limit on the
number of seeks / second.

	What file system are you using?  It can make a difference, and
surely has a bigger impact than most tweaks to the RAID subsystem.

	The biggest question in my mind, however, is why is random access a
big issue for you?  Are you running a very large relational database with
tens of thousands of tiny files?  For most systems, high volume accesses
consist mostly of large sequential I/O.  The majority of random I/O is of
rather short duration, meaning even with comparatively poor performance, it
doesn't take long to get the job done.  Fifty to eighty Megabits per second
is nothing at which to sneeze for random access of small files.  A few years
ago, many drives would have been barely able to manage that on a sustained
basis for sequential I/O.