Re: Planning a new server - help needed

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: PFC <lists(at)peufeu(dot)com>
Cc: James Mansion <james(at)mansionfamily(dot)plus(dot)com>, Laszlo Nagy <gandalf(at)shopzeus(dot)com>, pgsql-performance(at)postgresql(dot)org, Tony Nagy <tony(at)shopzeus(dot)com>
Subject: Re: Planning a new server - help needed
Date: 2008-03-30 04:45:36
Message-ID: Pine.GSO.4.64.0803300031060.5780@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Craig Ringer 2008-03-30 05:39:59 Re: Planning a new server - help needed
Previous Message Peter Eisentraut 2008-03-29 23:49:05 Re: Planning a new server - help needed