Re: Linux I/O tuning: CFQ vs. deadline

From: Scott Carey <scott(at)richrelevance(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Jeff <threshar(at)torgo(dot)978(dot)org>, "david(at)lang(dot)hm" <david(at)lang(dot)hm>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Subject: Re: Linux I/O tuning: CFQ vs. deadline
Date: 2010-02-10 18:04:38
Message-ID: FF5CEB38-D75C-4D97-A121-988452B55BFD@richrelevance.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


On Feb 9, 2010, at 10:37 PM, Greg Smith wrote:

> Jeff wrote:
>> I'd done some testing a while ago on the schedulers and at the time
>> deadline or noop smashed cfq. Now, it is 100% possible since then
>> that they've made vast improvements to cfq and or the VM to get better
>> or similar performance. I recall a vintage of 2.6 where they severely
>> messed up the VM. Glad I didn't upgrade to that one :)
>>
>> Here's the old post:
>> http://archives.postgresql.org/pgsql-performance/2008-04/msg00155.php
>
> pgiosim doesn't really mix writes into there though, does it? The mixed
> read/write situations are the ones where the scheduler stuff gets messy.
>

Also, read/write mix performance depend on the file system not just the scheduler.
The block device readahead parameter can have a big impact too.

If you test xfs, make sure you configure the 'allocsize' mount parameter properly as well. If there are any sequential reads or writes in there mixed with other reads/writes, that can have a big impact on how fragmented the filesystem gets.

Ext3 has several characteristics for writes that might favor cfq that other file systems do not. Features like delayed allocation, extents, and write barriers significantly change the pattern of writes seen by the I/O scheduler.

In short, one scheduler may be best for one filesystem, but not a good idea for others.

And then on top of that, it all depends on what type of DB you're running. Lots of small fast mostly read queries? Large number of small writes? Large bulk writes? Large reporting queries? Different configurations and tuning is required to maximize performance on each.

There is no single rule for Postgres on Linux that I can think of other than "never have ext3 in 'ordered' or 'journal' mode for your WAL on the same filesystem as your data".

> --
> Greg Smith 2ndQuadrant Baltimore, MD
> PostgreSQL Training, Services and Support
> greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com
>
>
> --
> 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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Robert Haas 2010-02-10 20:31:58 Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
Previous Message Andres Freund 2010-02-10 17:36:23 Re: Deferred constraint and delete performance