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

Re: Raid 10 chunksize

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Raid 10 chunksize
Date: 2009-03-26 17:39:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Thu, 26 Mar 2009, Mark Kirkwood wrote:

>> Also, if you want to minimize total I/O, you might drop 
>> bgwriter_lru_maxpages to 0.  That feature presumes you have some spare I/O 
>> capacity you use to prioritize lower latency, and it sounds like you don't. 
>> You get the lowest total I/O per transaction with the background writer 
>> turned off.
> Right - but then a big very noticeable stall when you do have to checkpoint? 
> We want to avoid that I think, even at the cost of a little overall 
> throughput.

There's not really a big difference if you're running with a large value 
for checkpoing_segments.  That spreads the checkpoint I/O over a longer 
period of time.  The current background writer doesn't aim to reduce 
writes at checkpoint time, because that never really worked out like 
people expected it to anyway.

It's aimed instead to write out buffers that database backend processes 
are going to need fairly soon, so they are less likely to block because 
they have to write them out themselves.  That leads to an occasional bit 
of wasted I/O, where the buffer written out gets used or dirtied against 
before it can be assigned to a backend.  I've got a long paper expanding 
on the documentation here you might find useful:

> Yeah - with 64K chunksize I'm seeing a result more congruent with yours 
> (866 or so for 24 clients)

That's good to hear.  If adjusting that helped so much, you might consider 
aligning the filesystem partitions to the chunk size too; the partition 
header usually screws that up on Linux.  See these two references for 

* Greg Smith gsmith(at)gregsmith(dot)com Baltimore, MD

In response to


pgsql-performance by date

Next:From: Scott CareyDate: 2009-03-26 21:44:15
Subject: Re: Raid 10 chunksize
Previous:From: Matthew WakelingDate: 2009-03-26 16:05:59
Subject: Re: Very specialised query

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