I believe they write at 200MB/s which is outstanding for sequential BW. Not sure about the write latency, though the Anandtech benchmark results showed high detail and IIRC the write latencies were very good.
- Luke ----- Original Message ----- From: da...@lang.hm <da...@lang.hm> To: Luke Lonergan Cc: st...@enterprisedb.com <st...@enterprisedb.com>; mar...@bluegap.ch <mar...@bluegap.ch>; scott.marl...@gmail.com <scott.marl...@gmail.com>; rjpe...@earthlink.net <rjpe...@earthlink.net>; pgsql-performance@postgresql.org <pgsql-performance@postgresql.org> Sent: Sat Jan 10 16:03:32 2009 Subject: Re: [PERFORM] understanding postgres issues/bottlenecks On Sat, 10 Jan 2009, Luke Lonergan wrote: > The new MLC based SSDs have better wear leveling tech and don't suffer > the pauses. Intel X25-M 80 and 160 GB SSDs are both pause-free. See > Anandtech's test results for details. they don't suffer the pauses, but they still don't have fantasic write speeds. David Lang > Intel's SLC SSDs should also be good enough but they're smaller. > > - Luke > > ----- Original Message ----- > From: pgsql-performance-ow...@postgresql.org > <pgsql-performance-ow...@postgresql.org> > To: Gregory Stark <st...@enterprisedb.com> > Cc: Markus Wanner <mar...@bluegap.ch>; Scott Marlowe > <scott.marl...@gmail.com>; Ron <rjpe...@earthlink.net>; > pgsql-performance@postgresql.org <pgsql-performance@postgresql.org> > Sent: Sat Jan 10 14:40:51 2009 > Subject: Re: [PERFORM] understanding postgres issues/bottlenecks > > On Sat, 10 Jan 2009, Gregory Stark wrote: > >> da...@lang.hm writes: >> >>> On Sat, 10 Jan 2009, Markus Wanner wrote: >>> >>>> My understanding of SSDs so far is, that they are not that bad at >>>> writing *on average*, but to perform wear-leveling, they sometimes have >>>> to shuffle around multiple blocks at once. So there are pretty awful >>>> spikes for writing latency (IIRC more than 100ms has been measured on >>>> cheaper disks). >> >> That would be fascinating. And frightening. A lot of people have been >> recommending these for WAL disks and this would be make them actually *worse* >> than regular drives. >> >>> well, I have one of those cheap disks. >>> >>> brand new out of the box, format the 32G drive, then copy large files to it >>> (~1G per file). this should do almost no wear-leveling, but it's write >>> performance is still poor and it has occasional 1 second pauses. >> >> This isn't similar to the way WAL behaves though. What you're testing is the >> behaviour when the bandwidth to the SSD is saturated. At that point some >> point >> in the stack, whether in the SSD, the USB hardware or driver, or OS buffer >> cache can start to queue up writes. The stalls you see could be the behaviour >> when that queue fills up and it needs to push back to higher layers. >> >> To simulate WAL you want to transfer smaller volumes of data, well below the >> bandwidth limit of the drive, fsync the data, then pause a bit repeat. Time >> each fsync and see whether the time they take is proportional to the amount >> of >> data written in the meantime or whether they randomly spike upwards. > > if you have a specific benchmark for me to test I would be happy to do > this. > > the test that I did is basicly the best-case for the SSD (more-or-less > sequential writes where the vendors claim that the drives match or > slightly outperform the traditional disks). for random writes the vendors > put SSDs at fewer IOPS than 5400 rpm drives, let along 15K rpm drives. > > take a look at this paper > http://www.imation.com/PageFiles/83/Imation-SSD-Performance-White-Paper.pdf > > this is not one of the low-performance drives, they include a sandisk > drive in the paper that shows significantly less performance (but the same > basic pattern) than the imation drives. > > David Lang > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
