Re: SSD + RAID - Mailing list pgsql-performance

I found a bit of time to play with this.

I started up a test with 20 concurrent processes all inserting into
the same table and committing after each insert.  The db was achieving
about 5000 inserts per second, and I kept it running for about 10
minutes.  The host was doing about 5MB/s of Physical I/O to the Fusion
IO drive. I set checkpoint segments very small (10).  I observed the
following message in the log: checkpoints are occurring too frequently
(16 seconds apart).  Then I pulled the cord.  On reboot I noticed that
Fusion IO replayed it's log, then the filesystem (vxfs) did the same.
Then I started up the DB and observed the it perform auto-recovery:

Nov 18 14:33:53 frutestdb002 postgres[5667]: [6-1] 2009-11-18 14:33:53
PSTLOG:  database system was not properly shut down; automatic
recovery in progress
Nov 18 14:33:53 frutestdb002 postgres[5667]: [7-1] 2009-11-18 14:33:53
PSTLOG:  redo starts at 2A/55F9D478
Nov 18 14:33:54 frutestdb002 postgres[5667]: [8-1] 2009-11-18 14:33:54
PSTLOG:  record with zero length at 2A/56692F38
Nov 18 14:33:54 frutestdb002 postgres[5667]: [9-1] 2009-11-18 14:33:54
PSTLOG:  redo done at 2A/56692F08
Nov 18 14:33:54 frutestdb002 postgres[5667]: [10-1] 2009-11-18
14:33:54 PSTLOG:  database system is ready

Thanks
Kenny

On Nov 13, 2009, at 1:35 PM, Kenny Gorman wrote:

> The FusionIO products are a little different.  They are card based
> vs trying to emulate a traditional disk.  In terms of volatility,
> they have an on-board capacitor that allows power to be supplied
> until all writes drain.  They do not have a cache in front of them
> like a disk-type SSD might.   I don't sell these things, I am just a
> fan.  I verified all this with the Fusion IO techs before I
> replied.  Perhaps older versions didn't have this functionality?  I
> am not sure.  I have already done some cold power off tests w/o
> problems, but I could up the workload a bit and retest.  I will do a
> couple of 'pull the cable' tests on monday or tuesday and report
> back how it goes.
>
> Re the performance #'s...  Here is my post:
>
> http://www.kennygorman.com/wordpress/?p=398
>
> -kg
>
>
> >In order for a drive to work reliably for database use such as for
> >PostgreSQL, it cannot have a volatile write cache.  You either need a
> >write cache with a battery backup (and a UPS doesn't count), or to
> turn
> >the cache off.  The SSD performance figures you've been looking at
> are
> >with the drive's write cache turned on, which means they're
> completely
> >fictitious and exaggerated upwards for your purposes.  In the real
> >world, that will result in database corruption after a crash one day.
> >No one on the drive benchmarking side of the industry seems to have
> >picked up on this, so you can't use any of those figures.  I'm not
> even
> >sure right now whether drives like Intel's will even meet their
> lifetime
> >expectations if they aren't allowed to use their internal volatile
> write
> >cache.
> >
> >Here's two links you should read and then reconsider your whole
> design:
> >
> >http://www.mysqlperformanceblog.com/2009/03/02/ssd-xfs-lvm-fsync-write-cache-barrier-and-lost-transactions/
> >http://petereisentraut.blogspot.com/2009/07/solid-state-drive-benchmarks-and-write.html
> >
> >I can't even imagine how bad the situation would be if you decide to
> >wander down the "use a bunch of really cheap SSD drives" path; these
> >things are barely usable for databases with Intel's hardware.  The
> needs
> >of people who want to throw SSD in a laptop and those of the
> enterprise
> >database market are really different, and if you believe doom
> >forecasting like the comments at
> >http://blogs.sun.com/BestPerf/entry/oracle_peoplesoft_payroll_sun_sparc
> >that gap is widening, not shrinking.
>
>