Re: a heavy duty operation on an "unused" table kills my server

From: Andy Colson <andy(at)squeakycode(dot)net>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org
Subject: Re: a heavy duty operation on an "unused" table kills my server
Date: 2010-01-14 18:15:33
Message-ID: 4B4F5F45.105@squeakycode.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2010-01-14 18:25:14 Re: Slow "Select count(*) ..." query on table with 60 Mio. rows
Previous Message Kevin Grittner 2010-01-14 18:12:17 Re: Slow "Select count(*) ..." query on table with 60 Mio. rows