Re: Optimizing Postgresql server and FreeBSD for heavy read and writes

From: Matthew Wakeling <matthew(at)flymine(dot)org>
To: Amitabh Kant <amitabhkant(at)gmail(dot)com>
Cc: Ivan Voras <ivoras(at)freebsd(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Optimizing Postgresql server and FreeBSD for heavy read and writes
Date: 2010-02-04 11:19:57
Message-ID: alpine.DEB.2.00.1002041113160.6195@aragorn.flymine.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, 4 Feb 2010, Amitabh Kant wrote:
> On Wed, Feb 3, 2010 at 10:05 PM, Ivan Voras <ivoras(at)freebsd(dot)org> wrote:
>> If you can, add another 2 drives in RAID 1 and move+symlink the pg_xlog
>> directory to the new array.
>
> Can't do anything about this server now, but would surely keep in mind
> before upgrading other servers. Would you recommend the same speed
> drives(15K SAS) for RAID 1, or would a slower drive also work here (10K SAS
> or even SATA II)?

The performance requirements for the WAL are significantly lower than for
the main database. This is for two reasons - firstly the WAL is
write-only, and has no other activity. The WAL only gets read again in the
event of a crash. Secondly, writes to the WAL are sequential writes, which
is the fastest mode of operation for a disc, whereas the main database
discs will have to handle random access.

The main thing you need to make sure of is that the WAL is on a disc
system that has a battery-backed up cache. That way, it will be able to
handle the high rate of fsyncs that the WAL generates, and the cache will
convert that into a simple sequential write. Otherwise, you will be
limited to one fsync every 5ms (or whatever the access speed of your WAL
discs is).

If you make sure of that, then there is no reason to get expensive fast
discs for the WAL at all (assuming they are expensive enough to not lie
about flushing writes properly).

Matthew

--
So, given 'D' is undeclared too, with a default of zero, C++ is equal to D.
mnw21, commenting on the "Surely the value of C++ is zero, but C is now 1"
response to "No, C++ isn't equal to D. 'C' is undeclared [...] C++ should
really be called 1" response to "C++ -- shouldn't it be called D?"

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tory M Blue 2010-02-04 18:15:56 bigint integers up to 19 digits.
Previous Message Simon Riggs 2010-02-04 10:41:13 Re: Air-traffic benchmark