On Feb 8, 2010, at 9:49 AM, Josh Berkus wrote:
>
> Those tests were also done on attached storage.
>
> So, what this suggests is:
> reads: deadline > CFQ
> writes: CFQ > deadline
> attached storage: deadline > CFQ
>
From my experience on reads:
Large sequential scans mixed with concurrent random reads behave very differently between the two schedulers.
Deadline has _significantly_ higher throughput in this situation, but the random read latency is higher. CFQ will
starvethe sequential scan in favor of letting each concurrent read get some time. If your app is very latency sensitive
onreads, that is good. If you need max throughput, getting the sequential scan out of the way instead of breaking it
upinto lots of small chunks is critical.
I think it is this behavior that causes the delays on writes -- from the scheduler's point of view, a large set of
writesis usually somewhat sequential and deadline favors throughput over latency.
Generally, my writes are large bulk writes, and I am not very latency sensitive but am very throughput sensitive. So
deadlinehelps a great deal (combined with decently sized readahead). Other use cases will clearly have different
preferences.
My experience with scheduler performace tuning is on CentOS 5.3 and 5.4. With the changes to much of the I/O layer in
thelatest kernels, I would not be surprised if things have changed.
> Man, we'd need a lot of testing to settle this. I guess that's why
> Linux gives us the choice of 4 ...
>
> --Josh Berkus
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
