pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Laurent Laborde <kerdezixe@gmail.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Ivan Voras <ivoras@freebsd.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: limiting performance impact of wal archiving.
Date: Tue, 10 Nov 2009 16:53:49 +0100
Message-ID: <8a1bfe660911100753nef2879by2c4f0b2215bf8f96@mail.gmail.com> (raw)
In-Reply-To: <4AF936F3020000250002C4F7@gw.wicourts.gov>
References: <8a1bfe660911100355l34a557ffj8244079c1fb689b5@mail.gmail.com>
	<hdbrv8$p35$1@ger.gmane.org>
	<8a1bfe660911100700l2a44f638m97ea6136b65deb21@mail.gmail.com>
	<hdbvqt$7v8$1@ger.gmane.org>
	<8a1bfe660911100729q42ac732cga9bbadd52e2533dd@mail.gmail.com>
	<4AF936F3020000250002C4F7@gw.wicourts.gov>

On Tue, Nov 10, 2009 at 4:48 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Laurent Laborde <kerdezixe@gmail.com> wrote:
>
>> BTW, if you have any idea to improve IO performance, i'll happily
>> read it.  We're 100% IO bound.
>
> At the risk of stating the obvious, you want to make sure you have
> high quality RAID adapters with large battery backed cache configured
> to write-back.

Not sure how "high quality" the 3ware is.
/c0 Driver Version = 2.26.08.004-2.6.18
/c0 Model = 9690SA-8I
/c0 Available Memory = 448MB
/c0 Firmware Version = FH9X 4.04.00.002
/c0 Bios Version = BE9X 4.01.00.010
/c0 Boot Loader Version = BL9X 3.08.00.001
/c0 Serial Number = L340501A7360026
/c0 PCB Version = Rev 041
/c0 PCHIP Version = 2.00
/c0 ACHIP Version = 1501290C
/c0 Controller Phys = 8
/c0 Connections = 8 of 128
/c0 Drives = 8 of 128
/c0 Units = 3 of 128
/c0 Active Drives = 8 of 128
/c0 Active Units = 3 of 32
/c0 Max Drives Per Unit = 32
/c0 Total Optimal Units = 2
/c0 Not Optimal Units = 1
/c0 Disk Spinup Policy = 1
/c0 Spinup Stagger Time Policy (sec) = 1
/c0 Auto-Carving Policy = off
/c0 Auto-Carving Size = 2048 GB
/c0 Auto-Rebuild Policy = on
/c0 Controller Bus Type = PCIe
/c0 Controller Bus Width = 8 lanes
/c0 Controller Bus Speed = 2.5 Gbps/lane


> If you haven't already done so, you might want to try
> elevator=deadline.

That's what we use.
Also tried "noop" scheduler without signifiant performance change.

-- 
ker2x



view thread (23+ messages)  latest in thread

Message-ID: <8a1bfe660911100753nef2879by2c4f0b2215bf8f96@mail.gmail.com>
Permalink:  ../8a1bfe660911100753nef2879by2c4f0b2215bf8f96@mail.gmail.com/
Also on:    postgresql.org/message-id/8a1bfe660911100753nef2879by2c4f0b2215bf8f96@mail.gmail.com

 · 

reply

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: kerdezixe@gmail.com, Kevin.Grittner@wicourts.gov, ivoras@freebsd.org
  Subject: Re: limiting performance impact of wal archiving.
  In-Reply-To: <8a1bfe660911100753nef2879by2c4f0b2215bf8f96@mail.gmail.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