Re: Effects of setting linux block device readahead size

Good question. I'm in the process of completing more exhaustive tests with
the various disk i/o schedulers.

Basic findings so far: it depends on what type of concurrency is going on.
Deadline has the best performance over a range of readahead values compared
to cfq or anticipatory with concurrent sequential reads with xfs. However,
mixing random and sequential reads puts cfq ahead with low readahead values
and deadline ahead with large readahead values (I have not tried
anticipatory here yet). However, your preference for prioritizing streaming
over random will significantly impact which you would want to use and at
what readahead value -- cfq does a better job at being consistent balancing
the two, deadline swings strongly to being streaming biased as the readahead
value gets larger and random biased when it is low. Deadline and CFQ are
similar with concurrent random reads. I have not gotten to any write tests
or concurrent read/write tests.

I expect the anticipatory scheduler to perform worse with mixed loads --
anything asking a raid array that can do 1000 iops to wait for 7 ms and do
nothing just in case a read in the same area might occur is a bad idea for
aggregate concurrent throughput. It is a scheduler that assumes the
underlying hardware is essentially one spindle -- which is why it is so good
in a standard PC or laptop. But, I could be wrong.

On Mon, Sep 15, 2008 at 9:18 AM, Matthew Wakeling <matthew(at)flymine(dot)org>wrote:

> On Thu, 11 Sep 2008, Scott Carey wrote:
>
>> Preliminary summary:
>>
>> readahead | 8 conc read rate | 1 conc read rate
>> 49152 | 311 | 314
>> 16384 | 312 | 312
>> 12288 | 304 | 309
>> 8192 | 292 |
>> 4096 | 264 |
>> 2048 | 211 |
>> 1024 | 162 | 302
>> 512 | 108 |
>> 256 | 81 | 300
>> 8 | 38 |
>>
>
> What io scheduler are you using? The anticipatory scheduler is meant to
> prevent this slowdown with multiple concurrent reads.
>
> Matthew
>
>
> --
> And the lexer will say "Oh look, there's a null string. Oooh, there's
> another. And another.", and will fall over spectacularly when it realises
> there are actually rather a lot.
> - Computer Science Lecturer (edited)
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>