Re: postgresql 8.3 tps rate

From: "M(dot) Edward (Ed) Borasky" <znmeb(at)cesmail(dot)net>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: postgresql 8.3 tps rate
Date: 2009-01-26 19:12:31
Message-ID: 497E0B1F.9030808@cesmail.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Craig Ringer wrote:
> M. Edward (Ed) Borasky wrote:
>
>> At the CMG meeting I asked the disk drive engineers, "well, if the
>> drives are doing the scheduling, why does Linux go to all the trouble?"
>
> One big reason is that Linux knows more about the relative importance of
> I/O operations than the individual drives do. Linux's scheduler supports
> priorities in its queuing, and is able to do things like try to perform
> small blocking reads before long non-blocking writes in order to improve
> overall system throughput.
>
> The individual drives just don't have the knowledge to make these
> decisions. All they can really do is try to fetch the set of blocks
> currently requested in the smallest possible time. This can even be
> harmful if, in order to improve overall throughput, the drive reorders
> what to the OS is a very high priority operation and performs it later
> than it would've if following the request queue directly.
>
> I've had to modify the 3ware driver to set very shallow request queues
> for similar reasons. It was using very deep queuing and the controller
> seems to do very stupid request queuing where it maintains a single deep
> per-controller queue rather than per-array queues, so I was getting
> AWFUL request latencies on high priority small reads when bulk I/O was
> in progress elsewhere - even on another array on the same controller.
>
> I've also had to turn NCQ off on SATA disks before because it was
> foiling Linux's I/O priority management, so tasks with low ionice levels
> still ended up rather severely impacting system responsiveness.
>
> Hopefully these devices will end up with the smarts to manage I/O in a
> priority queue where read latency is considered as well as throughput.
>
>> Their answer was something like, "smart disk drives are a relatively
>> recent invention." But
>
> --
> Craig Ringer
>

Thanks!! Is there a howto somewhere on disabling this on a Seagate
Barracuda? I'm in the middle of rebuilding my tools and analysis
algorithms as a "real open source project", and I'd love to be able to
have some working examples that people without access to industrial
strength I/O subsystems can use. :)

--
M. Edward (Ed) Borasky

I've never met a happy clam. In fact, most of them were pretty steamed.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2009-01-26 19:26:55 Re: postgresql 8.3 tps rate
Previous Message Craig Ringer 2009-01-26 18:09:11 Re: postgresql 8.3 tps rate