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

Re: Best use of second controller with faster disks?

From: Vivek Khera <vivek(at)khera(dot)org>
To: Pgsql performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Best use of second controller with faster disks?
Date: 2007-06-12 18:24:59
Message-ID: A344D322-CE47-4723-9288-EF67563DB9B2@khera.org (view raw or flat)
Thread:
Lists: pgsql-performance
On Jun 11, 2007, at 9:14 PM, Francisco Reyes wrote:

> RAID card 1 with 8 drives. 7200 RPM SATA RAID10
> RAID card 2 with 4 drives. 10K RPM SATA RAID10
>

what raid card have you got?  i'm playing with an external enclosure  
which has an areca sata raid in it and connects to the host via fibre  
channel.  it is wicked fast, and supports a RAID6 which seems to be  
as fast as the RAID10 in my initial testing on this unit.

What drives are you booting from?  If you're booting from the 4-drive  
RAID10, perhaps split that into a pair of RAID1's and boot from one  
and use the other as the pg log disk.

however, I must say that with my 16 disk array, peeling the log off  
the main volume actually slowed it down a bit.  I think that the raid  
card is just so fast at doing the RAID6 computations and having the  
striping is a big gain over the dedicated RAID1 for the log.

Right now I'm testing an 8-disk RAID6 configuration on the same   
device; it seems slower than the 16-disk RAID6, but I haven't yet  
tried 8-disk RAID10 with dedicated log yet.

> Besides having pg_xlog in the 10K RPM drives what else can I do to  
> best use those drives other than putting some data in them?
>
> Iostat shows the drives getting used very little, even during  
> constant updates and vacuum.
>
> Some of the postgresl.conf settings that may be relevant.
> wal_buffers = 64
> checkpoint_segments = 64

i'd bump checkpoint_segements up to 256 given the amount of disk  
you've got dedicated to it.  be sure to increase checkpoint timeout too.

And if you can move to 6.2 FreeBSD you should pick up some speed on  
the network layer and possibly the disk I/O.


In response to

Responses

pgsql-performance by date

Next:From: Steven FlattDate: 2007-06-12 18:31:01
Subject: Re: performance drop on 8.2.4, reverting to 8.1.4
Previous:From: Heikki LinnakangasDate: 2007-06-12 18:20:51
Subject: Re: Variable (degrading) performance

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