Re: a heavy duty operation on an "unused" table kills my server
От | Andy Colson |
---|---|
Тема | Re: a heavy duty operation on an "unused" table kills my server |
Дата | |
Msg-id | 4B4F5F45.105@squeakycode.net обсуждение исходный текст |
Ответ на | Re: a heavy duty operation on an "unused" table kills my server (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: a heavy duty operation on an "unused" table kills my
server
|
Список | pgsql-performance |
On 1/14/2010 12:07 PM, Greg Smith wrote: > Andy Colson wrote: >> On 1/13/2010 11:36 PM, Craig Ringer wrote: >>> Yes. My 3ware 8500-8 on a Debian Sarge box was so awful that launching a >>> terminal would go from a 1/4 second operation to a 5 minute operation >>> under heavy write load by one writer. I landed up having to modify the >>> driver to partially mitigate the issue, but a single user on the >>> terminal server performing any sort of heavy writing would still >>> absolutely nuke performance. >> >> On a side note, on linux, would using the deadline scheduler resolve >> that? > > I've never seen the deadline scheduler resolve anything. If you're out > of I/O capacity and that's blocking other work, performance is dominated > by the policies of the underlying controller/device caches. Think about > it a minute: disks nowadays can easily have 32MB of buffer in them, > right? And random read/write operations are lucky to clear 2MB/s on > cheap drivers. So once the drive is filled with requests, you can easily > sit there for ten seconds before the scheduler even has any input on > resolving the situation. That's even more true if you've got a larger > controller cache in the mix. > That makes sense. So if there is very little io, or if there is way way too much, then the scheduler really doesn't matter. So there is a slim middle ground where the io is within a small percent of the HD capacity where the scheduler might make a difference? -Andy
В списке pgsql-performance по дате отправления: