Re: linux deadline i/o elevator tuning

The anticipatory scheduler gets absolutely atrocious performance for server
workloads on even moderate server hardware. It is applicable only to single
spindle setups on desktop-like worlkoads.

Seriously, never use this for a database. It _literally_ will limit you to
100 iops maximum random access iops by waiting 10ms for 'nearby' LBA
requests.

For Postgres, deadline, cfq, and noop are the main options.

Noop is good for ssds and a few high performance hardware caching RAID cards
(and only a few of the good ones), and poor otherwise.

Cfq tends to favor random access over sequential access in mixed load
environments and does not tend to favor reads over writes. Because it
batches its elevator algorithm by requesting process, it becomes less
efficient with lots of spindles where multiple processes have requests from
nearby disk regions.

Deadline tends to favor reads over writes and slightly favor sequential
access to random access (and gets more MB/sec on average as a result in
mixed loads). It tends to work well for large stand-alone servers and not
as well for desktop/workstation type loads.

I have done a little tuning of the parameters of cfq and deadline, and never
noticed much difference. I suppose you could shift the deadline biases to
read or write with these.

On 4/9/09 7:27 AM, "Grzegorz Jaśkiewicz" <gryzman(at)gmail(dot)com> wrote:

> acording to kernel folks, anticipatory scheduler is even better for dbs.
> Oh well, it probably means everyone has to test it on their own at the
> end of day.
>
> --
> 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
>