Re: Performance increase with elevator=deadline
От | Jeff |
---|---|
Тема | Re: Performance increase with elevator=deadline |
Дата | |
Msg-id | C050E63A-2209-4E89-AA99-6A327CCE7380@torgo.978.org обсуждение исходный текст |
Ответ на | Performance increase with elevator=deadline ("Albe Laurenz" <laurenz.albe@wien.gv.at>) |
Ответы |
Re: Performance increase with elevator=deadline
Re: Performance increase with elevator=deadline |
Список | 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@jefftrout.com> http://www.stuarthamm.net/ http://www.dellsmartexitin.com/
В списке pgsql-performance по дате отправления: