Message-ID: <4DC88905.8030200@boreham.org>
Date: Mon, 09 May 2011 18:38:29 -0600
From: David Boreham <david_list@boreham.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
	rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "pgsql-performance@postgresql.org >> PGSQL Performance"
	<pgsql-performance@postgresql.org>
Subject: Re: Benchmarking a large server
References: <BANLkTikONPZ_7zQNfbyyN4MGBnn5PXHrAg@mail.gmail.com>
	<BANLkTikecJCGWH0WyKFiSnC08kmcwS7FqA@mail.gmail.com>
	<4DC88793.4000708@emolecules.com>
In-Reply-To: <4DC88793.4000708@emolecules.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 5/9/2011 6:32 PM, Craig James wrote:
> Maybe this is a dumb question, but why do you care?  If you have 1TB 
> RAM and just a little more actual disk space, it seems like your 
> database will always be cached in memory anyway.  If you "eliminate 
> the cach effect," won't the benchmark actually give you the wrong 
> real-life results?

The time it takes to populate the cache from a cold start might be 
important.

Also, if it were me, I'd be wanting to check for weird performance 
behavior at this memory scale.
I've seen cases in the past where the VM subsystem went bananas because 
the designers
and testers of its algorithms never considered the physical memory size 
we deployed.

How many times was the kernel tested with this much memory, for example 
? (never??)