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

Re: raid10 write performance

From: Scott Carey <scott(at)richrelevance(dot)com>
To: Karl Denninger <karl(at)denninger(dot)net>
Cc: Justin Graf <justin(at)magwerks(dot)com>, Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: raid10 write performance
Date: 2010-06-22 17:19:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Jun 22, 2010, at 7:29 AM, Karl Denninger wrote:

> Justin Graf wrote:
>> On 6/22/2010 4:31 AM, Grzegorz Jaśkiewicz wrote:
>>> Would moving WAL dir to separate disk help potentially ?
>> Yes it can have a big impact.
> WAL on a separate spindle will make a HUGE difference in performance.  TPS rates frequently double OR BETTER with WAL on a dedicated spindle.
> Strongly recommended.

Most of the performance increase on Linux, if your RAID card has a data-safe write-back cache (battery or solid state cache persistence in case of power failure), is a separate file system, not separate spindle.   Especially if ext3 is used with the default "ordered" journal, it is absolutely caustic to performance to have WAL and data on the same file system.  

The whole 'separate spindle' thing is important if you don't have a good caching raid card, otherwise it doesn't matter that much.

> Be aware that you must pay CLOSE ATTENTION to your backup strategy if WAL is on a different physical disk.  Snapshotting the data disk where WAL is on a separate spindle and backing it up **WILL NOT WORK** and **WILL** result in an non-restoreable backup.
> The manual discusses this but it's easy to miss.... don't or you'll get a NASTY surprise if something goes wrong.....
> -- Karl
> <karl.vcf><ATT00001..txt>

In response to

pgsql-performance by date

Next:From: Scott CareyDate: 2010-06-22 17:30:35
Subject: ALTER Table and CLUSTER does adding a new column rewrite clustered? (8.4.3)
Previous:From: Dave CrookeDate: 2010-06-22 16:01:28
Subject: Re: raid10 write performance

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