Re: SSD + RAID

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.
>
>