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

Re: Migrating to Postgresql and new hardware

From: Lars <la(at)unifaun(dot)com>
To: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>
Subject: Re: Migrating to Postgresql and new hardware
Date: 2011-01-31 10:12:33
Message-ID: E0B1224AD40B544B9DE1BCC6008E95220D1F1935DC@UF05.unifaun.se (view raw or flat)
Thread:
Lists: pgsql-performance
Interesting.
Would have been nice if the test was with a raid-10 setup as raid-5 is not very good for writes...

Would you get much of a performance increase with a write-cached ssd even if you got a raid controller with (battery-backed) cache?

/Lars

-----Ursprungligt meddelande-----
Från: Greg Smith [mailto:greg(at)2ndquadrant(dot)com]
Skickat: den 29 januari 2011 01:27
Till: Lars
Kopia: mark; pgsql-performance(at)postgresql(dot)org
Ämne: Re: [PERFORM] Migrating to Postgresql and new hardware

Lars wrote:
> Below is a quote from the Pliant datasheet:
> "No Write Cache:
> Pliant EFDs deliver outstanding
> write performance
> without any dependence on
> write cache and thus does
> not use battery/supercap."
>

I liked the article The Register wrote about them, with the headline
"Pliant's SSDs are awesome, says Pliant".  Of course they do.  Check out
the write benchmark figures in the information review at
http://oliveraaltonen.com/2010/09/29/preliminary-benchmark-results-of-the-pliant-ssd-drives/
to see how badly performance suffers on their design from those
decisions.  The Fusion I/O devices get nearly an order of magnitude more
write IOPS in those tests.

As far as I've been able to tell, what Pliant does is just push writes
out all the time without waiting for them to be aligned with block
sizes, followed by cleaning up the wreckage later via their internal
automatic maintenance ASICs (it's sort of an always on TRIM
implementation if I'm guessing right).  That has significant limitations
both in regards to total write speed as well as device longevity.  For a
database, I'd much rather have a supercap and get ultimate write
performance without those downsides.  Depends on the read/write ratio
though; I could see a heavily read-biased system work well with their
approach.  Of course, a heavily read-based system would be better served
by having a ton of RAM instead in most cases.

Could be worst though--they could be misleading about the whole topic of
write durability like Intel is.  I consider claiming high performance
when you don't always really have it, what Pliant is doing here, to be a
much lesser sin than losing data at random and not being clear about
when that can happen.  I'd like FusionIO to put a big "expect your
server to be down for many minutes after a power interruption" warning
on their drives, too, while I'm wishing for complete vendor transparency
here.

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


In response to

pgsql-performance by date

Next:From: LewDate: 2011-01-31 12:28:39
Subject: Re: Any experience using "shake" defragmenter?
Previous:From: Mladen GogalaDate: 2011-01-31 04:38:38
Subject: Re: Any experience using "shake" defragmenter?

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