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

Re: Performance increase with elevator=deadline

From: Jeff <threshar(at)torgo(dot)978(dot)org>
To: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Performance increase with elevator=deadline
Date: 2008-04-11 15:09:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Apr 11, 2008, at 7:22 AM, Albe Laurenz wrote:
> After some time of trial and error we found that changing the I/O  
> scheduling
> algorithm to "deadline" improved I/O performance by a factor 4 (!) for
> this specific load test.
I was inspired once again to look into this - as I'm recently hitting  
some glass ceilings with my machines.

I have a little app I wrote called pgiosim (its on pgfoundry - 
  that basically just opens some files, and does random seeks and 8kB  
reads, much like what our beloved PG does.

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'll be trying this out on the big array later today.  I found it  
suprising this info wasn't more widespread (the use of CFQ on a good  

it also seems changing elevators on the fly works fine (echo  
schedulername > /sys/block/.../queue/scheduler  I admit I sat there  
flipping back and forth going "disk go fast.. disk go slow.. disk go  
fast... " :)

Jeff Trout <jeff(at)jefftrout(dot)com>

In response to


pgsql-performance by date

Next:From: Jon StewartDate: 2008-04-11 15:28:55
Subject: Re: Creating large database of MD5 hash values
Previous:From: Gregory StarkDate: 2008-04-11 14:47:17
Subject: Re: Performance increase with elevator=deadline

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