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

From: Matthew Wakeling <matthew(at)flymine(dot)org>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Andy Colson <andy(at)squeakycode(dot)net>, 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-15 10:55:00
Message-ID: alpine.DEB.2.00.1001151022100.6195@aragorn.flymine.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, 14 Jan 2010, Greg Smith wrote:
> Andy Colson wrote:
>> 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?
>
> That's basically how I see it. There seem to be people who run into
> workloads in the middle ground where the scheduler makes a world of
> difference. I've never seen one myself, and suspect that some of the reports
> of deadline being a big improvement just relate to some buginess in the
> default CFQ implementation that I just haven't encountered.

That's the perception I get. CFQ is the default scheduler, but in most
systems I have seen, it performs worse than the other three schedulers,
all of which seem to have identical performance. I would avoid
anticipatory on a RAID array though.

It seems to me that CFQ is simply bandwidth limited by the extra
processing it has to perform.

Matthew

--
Experience is what allows you to recognise a mistake the second time you
make it.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Matthew Wakeling 2010-01-15 11:09:13 Re: Inserting 8MB bytea: just 25% of disk perf used?
Previous Message Pierre Frédéric Caillaud 2010-01-15 09:50:42 Re: Inserting 8MB bytea: just 25% of disk perf used?