Skip site navigation (1) Skip section navigation (2)

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

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, 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-08 18:59:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Mon, Feb 8, 2010 at 10:49 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> That's basically what I've been trying to make clear all along:  people
>> should keep an open mind, watch what happens, and not make any
>> assumptions.  There's no clear cut preference for one scheduler or the
>> other in all situations.  I've seen CFQ do much better, you and Albe
>> report situations where the opposite is true.  I was just happy to see
>> another report of someone running into the same sort of issue I've been
>> seeing, because I didn't have very much data to offer about why the
>> standard advice of "always use deadline for a database app" might not
>> apply to everyone.
> Damn, you would have to make things complicated, eh?
> FWIW, back when deadline was first introduced Mark Wong did some tests
> and found Deadline to be the fastest of 4 on DBT2 ... but only by about
> 5%.  If the read vs. checkpoint analysis is correct, what was happening
> is the penalty for checkpoints on deadline was almost wiping out the
> advantage for reads, but not quite.
> Those tests were also done on attached storage.
> So, what this suggests is:
> reads:  deadline > CFQ
> writes: CFQ > deadline
> attached storage:  deadline > CFQ
> Man, we'd need a lot of testing to settle this.  I guess that's why
> Linux gives us the choice of 4 ...

Just to add to the data points.  On an 8 core opteron Areca 1680 and a
12 disk RAID-10 for data and 2 disk RAID-1 for WAL, I get noticeably
better performance (approximately 15%) and lower load factors (they
drop from about 8 to 5 or 6) running noop over the default scheduler,
with RHEL 5.4 with the 2.6.18-92.el5 kernel from RHEL 5.2.

In response to

pgsql-performance by date

Next:From: Andres FreundDate: 2010-02-08 19:29:46
Subject: Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
Previous:From: Greg StarkDate: 2010-02-08 18:34:01
Subject: Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group