Re: SSD + RAID
От | Kenny Gorman |
---|---|
Тема | Re: SSD + RAID |
Дата | |
Msg-id | 7FF9A3C8-56BB-45EA-9D96-421ED481E75F@hi5.com обсуждение исходный текст |
Ответ на | Re: SSD + RAID ("Kenny Gorman" <KGorman@hi5.com>) |
Список | 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. > >
В списке pgsql-performance по дате отправления: