Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


pgsql-performance by date

Next:From: Greg SmithDate: 2009-01-26 19:26:55
Subject: Re: postgresql 8.3 tps rate
Previous:From: Craig RingerDate: 2009-01-26 18:09:11
Subject: Re: postgresql 8.3 tps rate

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group