Message-ID: <4DC8C2B1.1020004@2ndQuadrant.com>
Date: Tue, 10 May 2011 00:44:33 -0400
From: Greg Smith <greg@2ndQuadrant.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Benchmarking a large server
References: <BANLkTikONPZ_7zQNfbyyN4MGBnn5PXHrAg@mail.gmail.com>
	<BANLkTikecJCGWH0WyKFiSnC08kmcwS7FqA@mail.gmail.com>
	<4DC88793.4000708@emolecules.com>, <4DC88905.8030200@boreham.org>
	<0683F5F5A5C7FE419A752A034B4A0B9702B61997@sswchi5pmbx2.peak6.net>
In-Reply-To: <0683F5F5A5C7FE419A752A034B4A0B9702B61997@sswchi5pmbx2.peak6.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 05/09/2011 11:13 PM, Shaun Thomas wrote:
> Take a look at /proc/sys/vm/dirty_ratio and 
> /proc/sys/vm/dirty_background_ratio if you have an older Linux system, 
> or /proc/sys/vm/dirty_bytes, and /proc/sys/vm/dirty_background_bytes 
> with a newer one.
> On older systems for instance, those are set to 40 and 20 respectively (recent kernels cut these in half).

1/4 actually; 10% and 5% starting in kernel 2.6.22.  The main sources of 
this on otherwise new servers I see are RedHat Linux RHEL5 systems  
running 2.6.18.  But as you say, even the lower defaults of the newer 
kernels can be way too much on a system with lots of RAM.

The main downside I've seen of addressing this by using a kernel with 
dirty_bytes and dirty_background_bytes is that VACUUM can slow down 
considerably.  It really relies on the filesystem having a lot of write 
cache to perform well.  In many cases people are happy with VACUUM 
throttling if it means nasty I/O spikes go away, but the trade-offs here 
are still painful at times.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books