Re: a heavy duty operation on an "unused" table kills my server - Mailing list pgsql-performance

From Andy Colson
Subject Re: a heavy duty operation on an "unused" table kills my server
Date
Msg-id 4B4F5F45.105@squeakycode.net
Whole thread Raw
In response to Re: a heavy duty operation on an "unused" table kills my server  (Greg Smith <greg@2ndquadrant.com>)
Responses Re: a heavy duty operation on an "unused" table kills my server
List 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 by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
Next
From: Greg Smith
Date:
Subject: Re: Slow "Select count(*) ..." query on table with 60 Mio. rows