From: Greg Smith <gsmith@gregsmith.com>
To: pgsql-performance@postgresql.org
Subject: Re: Bad iostat numbers
Date: Tue, 5 Dec 2006 23:54:58 -0500 (EST)
Message-ID: <Pine.GSO.4.64.0612052327080.7579@westnet.com> (raw)
In-Reply-To: <4575864A.8060005@modgraph-usa.com>
References: <PEEPKDFEHHEMKBBFPOOKKEHCDKAA.carlos.reimer@opendb.com.br>
<Pine.GSO.4.64.0612032336250.19679@westnet.com>
<33c6269f0612032317t9f0bc77n3ff791a5cd88fc80@mail.gmail.com>
<Pine.GSO.4.64.0612041946120.9323@westnet.com>
<33c6269f0612042221x5820e98bl96f8d0dc4a87bd3f@mail.gmail.com>
<20061205121507.GZ1622@mathom.us>
<33c6269f0612050457s4a8eb0eas662d7a50fb5dfa89@mail.gmail.com>
<4575864A.8060005@modgraph-usa.com>
On Tue, 5 Dec 2006, Craig A. James wrote:
> I'm not familiar with the inner details of software RAID, but the only
> circumstance I can see where things would get corrupted is if the RAID driver
> writes a LOT of blocks to one disk of the array before synchronizing the
> others...
You're talking about whether the discs in the RAID are kept consistant.
While it's helpful with that, too, that's not the main reason a the
battery-backed cache is so helpful. When PostgreSQL writes to the WAL, it
waits until that data has really been placed on the drive before it enters
that update into the database. In a normal situation, that means that you
have to pause until the disk has physically written the blocks out, and
that puts a fairly low upper limit on write performance that's based on
how fast your drives rotate. RAID 0, RAID 1, none of that will speed up
the time it takes to complete a single synchronized WAL write.
When your controller has a battery-backed cache, it can immediately tell
Postgres that the WAL write completed succesfully, while actually putting
it on the disk later. On my systems, this results in simple writes going
2-4X as fast as they do without a cache. Should there be a PC failure, as
long as power is restored before the battery runs out that transaction
will be preserved.
What Alex is rightly pointing out is that a software RAID approach doesn't
have this feature. In fact, in this area performance can be even worse
under SW RAID than what you get from a single disk, because you may have
to wait for multiple discs to spin to the correct position and write data
out before you can consider the transaction complete.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: gsmith@gregsmith.com
Subject: Re: Bad iostat numbers
In-Reply-To: <Pine.GSO.4.64.0612052327080.7579@westnet.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox