DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=mXBpoLRVg1GWFuCOGIFlQhuenlSMH6FDJoq5hJQ5Hj9JB1hF8PqDsfLhpCxJHHjQo8
	QBTV55+SxjdI1/sYMbGkSAS31bQGqIkyoisQWYd+tJd0H42dkMJqLYGTMKLAlto+cG3O
	QWF+ISIGSWyKMs6xr1k57cvxTYbq8pSZv/lso=
MIME-Version: 1.0
In-Reply-To: <4B704EA0.3050906@agliodbs.com>
References: <4B6FDD26.9010106@2ndquadrant.com>
	<D960CB61B694CF459DCFB4B0128514C203938157@exadv11.host.magwien.gv.at>
	<4B6FD868020000250002F084@gw.wicourts.gov>
	<4B702E05.1000708@2ndquadrant.com> <4B704EA0.3050906@agliodbs.com>
Date: Mon, 8 Feb 2010 11:59:09 -0700
Message-ID: <dcc563d11002081059q33c9dcd5v9006482a54f01d23@mail.gmail.com>
Subject: Re: Linux I/O tuning: CFQ vs. deadline
From: Scott Marlowe <scott.marlowe@gmail.com>
To: Josh Berkus <josh@agliodbs.com>
Cc: Greg Smith <greg@2ndquadrant.com>,
	Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	pgsql-performance@postgresql.org, Albe Laurenz <laurenz.albe@wien.gv.at>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 8, 2010 at 10:49 AM, Josh Berkus <josh@agliodbs.com> wrote:
>
>> That's basically what I've been trying to make clear all along: =A0peopl=
e
>> should keep an open mind, watch what happens, and not make any
>> assumptions. =A0There's no clear cut preference for one scheduler or the
>> other in all situations. =A0I've seen CFQ do much better, you and Albe
>> report situations where the opposite is true. =A0I 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%. =A0If 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: =A0deadline > CFQ
> writes: CFQ > deadline
> attached storage: =A0deadline > CFQ
>
> Man, we'd need a lot of testing to settle this. =A0I 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.