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: | C050E63A-2209-4E89-AA99-6A327CCE7380@torgo.978.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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 - http://pgfoundry.org/projects/pgiosim)
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
controller).
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>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Jon Stewart | 2008-04-11 15:28:55 | Re: Creating large database of MD5 hash values |
Previous Message | Gregory Stark | 2008-04-11 14:47:17 | Re: Performance increase with elevator=deadline |