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@xxxxxxxxx> 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@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
