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.
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
