Re: understanding postgres issues/bottlenecks
От | david@lang.hm |
---|---|
Тема | Re: understanding postgres issues/bottlenecks |
Дата | |
Msg-id | alpine.DEB.1.10.0901101602050.6192@asgard.lang.hm обсуждение исходный текст |
Ответ на | understanding postgres issues/bottlenecks (Stefano Nichele <stefano.nichele@gmail.com>) |
Ответы |
Re: understanding postgres issues/bottlenecks
(Mark Kirkwood <markir@paradise.net.nz>)
|
Список | pgsql-performance |
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-owner@postgresql.org <pgsql-performance-owner@postgresql.org> > To: Gregory Stark <stark@enterprisedb.com> > Cc: Markus Wanner <markus@bluegap.ch>; Scott Marlowe <scott.marlowe@gmail.com>; Ron <rjpeace@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: > >> david@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 >
В списке pgsql-performance по дате отправления: