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

Re: Performance increase with elevator=deadline

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Matthew <matthew(at)flymine(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance increase with elevator=deadline
Date: 2008-04-11 18:03:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Matthew wrote:
> On Fri, 11 Apr 2008, Jeff wrote:
>> Using 4 of these with a dataset of about 30GB across a few files 
>> (Machine has 8GB mem) I went from around 100 io/sec to 330 changing to 
>> noop.   Quite an improvement.  If you have a decent controller CFQ is 
>> not what you want.   I tried deadline as well and it was a touch 
>> slower.  The controller is a 3ware 9550sx with 4 disks in a raid10.
> I ran Greg's fadvise test program a while back on a 12-disc array. The 
> three schedulers (deadline, noop, anticipatory) all performed 
> pretty-much the same, with the fourth (cfq, the default) being 
> consistently slower.

I use CFQ on some of my servers, despite the fact that it's often slower 
in total throughput terms, because it delivers much more predictable I/O 
latencies that help prevent light I/O processes being starved by heavy 
I/O processes. In particular, an Linux terminal server used at work has 
taken a lot of I/O tuning before it delivers even faintly acceptable I/O 
latencies under any sort of load.

Bounded I/O latency at the expense of throughput is not what you usually 
want on a DB server, where throughput is king, so I'm not at all 
surprised that CFQ performs poorly for PostgreSQL. I've done no testing 
on that myself, though, because with my DB size and the nature of my 
queries most of them are CPU bound anyway.

Speaking of I/O performance with PostgreSQL, has anybody here done any 
testing to compare results with LVM to results with the same filesystem 
on a conventionally partitioned or raw volume? I'd probably use LVM even 
at a performance cost because of its admin benefits, but I'd be curious 
if there is any known cost for use with Pg. I've never been able to 
measure one with other workloads.

Craig Ringer

In response to


pgsql-performance by date

Next:From: Greg SmithDate: 2008-04-11 19:56:36
Subject: Re: Performance increase with elevator=deadline
Previous:From: Florian WeimerDate: 2008-04-11 17:04:00
Subject: Re: Creating large database of MD5 hash values

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