Date: Sun, 30 Mar 2008 00:45:36 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
To: PFC <lists@peufeu.com>
cc: James Mansion <james@mansionfamily.plus.com>,
	Laszlo Nagy <gandalf@shopzeus.com>, pgsql-performance@postgresql.org,
	Tony Nagy <tony@shopzeus.com>
Subject: Re: Planning a new server - help needed
In-Reply-To: <op.t8r6d212cigqcu@apollo13.peufeu.com>
Message-ID: <Pine.GSO.4.64.0803300031060.5780@westnet.com>
References: <47ECB4F6.1040901@shopzeus.com>
	<Pine.GSO.4.64.0803281300240.2521@westnet.com>
	<47EE1B1F.20506@mansionfamily.plus.com>
	<op.t8r6d212cigqcu@apollo13.peufeu.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Sat, 29 Mar 2008, PFC wrote:

>> Why do you claim that 'More platters also means slower seeks
>> and generally slower performance.'?
> 	More platters -> more heads -> heavier head assembly -> slower seek 
> time

I recall seeing many designs with more platters that have slower seek 
times in benchmarks, and I always presumed this was the reason.  That's 
the basis for that comment.  I'll disclaim that section a bit.

> Actually, now that 8.3 can sync to disk every second instead of at every 
> commit, I wonder, did someone do some enlightening benchmarks ?

I've seen some really heavy workloads where using async commit helped 
group commits in a larger batches usefully, but I personally haven't found 
it to be all that useful if you're already got a caching controller to 
accelerate writes on the kinds of hardware most people have.  It's a great 
solution for situations without a usable write cache though.

> Also, there is a thing called write barriers, which supposedly could be 
> used to implement fsync-like behaviour without the penalty, if the disk, 
> the OS, the controller, and the filesystem support it (that's a lot of 
> ifs)...

The database can't use fsync-like behavior for the things it calls fsync 
for; it needs the full semantics.  You're either doing the full operation, 
or you're cheating and it doesn't do what it's supposed to.  Write 
barriers aren't any improvement over a good direct I/O sync write setup 
for the WAL.  There may be some limited value to that approach for the 
database writes at checkpoint time, but again there's a real fsync coming 
at the end of that and it's not satisfied until everything is on disk (or 
in a good disk controller cache).

> Gigabyte should revamp their i-RAM to use ECC RAM of a larger 
> capacity... and longer lasting battery backup...

I saw a rumor somewhere that they were close to having a new version of 
that using DDR2 ready, which would make it pretty easy to have 8GB on 
there.

> I wonder, how many write cycles those Flash drives can take before 
> reliability becomes a problem...

The newer SSD drives with good write leveling should last at least as long 
as you'd expect a mechanical drive to, even in a WAL application.  Lesser 
grades of flash used as disk could be a problem though.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD