In my tests, I have never seen the readahead value affect random access performance (kernel 2.6.18 +). At the extreme, I tried a 128MB readahead, and random I/O rates were the same. This was with CentOS 5.2, other confirmation of this would be useful. The Linux readahead algorithm is smart enough to only seek ahead after detecting sequential access. The readahead algorithm has had various improvements to reduce the need to tune it from 2.6.18 to 2.6.24, but from what I gather, this tuning is skewed towards desktop/workstation drives and not large RAID arrays.
> Effect of ReadAhead Settings
> disabled,256(default) , 512,1024
>
> xfs_ra0 414741 , 66144
> xfs_ra256 403647, 545026 all tests on sda6
> xfs_ra512 411357, 564769
> xfs_ra1024 404392, 431168
>
> looks like 512 was the best setting for this controller
That's only known for sequential access.
How did it perform under the random access, or did the numbers not
change too much?
The readaheaed value DOES affect random access as a side effect in favor of sequential reads when there is mixed random/sequential load, by decreasing the ‘read fragmentation’ effect of mixing random seeks into a sequential request stream. For most database loads, this is a good thing, since it increases total bytes read per unit of time, effectively ‘getting out of the way’ a sequential read rather than making it drag on for a long time by splitting it into non-sequential I/O’s while other random access is concurrent.
