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
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 |