pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedSSD database benchmarks
4+ messages / 3 participants
[nested] [flat]
* SSD database benchmarks
@ 2008-04-29 18:55 Greg Smith <gsmith@gregsmith.com>
0 siblings, 2 replies; 4+ messages in thread
From: Greg Smith @ 2008-04-29 18:55 UTC (permalink / raw)
To: pgsql-performance
This is the best write-up I've seen yet on quantifying what SSDs are good
and bad at in a database context:
http://www.bigdbahead.com/?p=37
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: SSD database benchmarks
@ 2008-04-29 20:00 Guido Neitzer <lists@event-s.net>
parent: Greg Smith <gsmith@gregsmith.com>
1 sibling, 1 reply; 4+ messages in thread
From: Guido Neitzer @ 2008-04-29 20:00 UTC (permalink / raw)
To: pgsql-performance
On 29.04.2008, at 12:55, Greg Smith wrote:
> This is the best write-up I've seen yet on quantifying what SSDs are
> good and bad at in a database context:
>
> http://www.bigdbahead.com/?p=37
They totally missed "mainly write" applications which most of my
applications are. Reads in a OLTP setup are typically coming from a
cache (or, like in our case an index like Solr) while writes go
through ... So you might get some decent IO from the SSD when the
database just started up without caches filled, but as long as your
cache hit ratio is good, it doesn't matter anymore after a couple of
minutes.
Nevertheless it's an interesting development.
cug
--
http://www.event-s.net
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: SSD database benchmarks
@ 2008-04-29 23:26 Greg Smith <gsmith@gregsmith.com>
parent: Guido Neitzer <lists@event-s.net>
0 siblings, 0 replies; 4+ messages in thread
From: Greg Smith @ 2008-04-29 23:26 UTC (permalink / raw)
To: Guido Neitzer <lists@event-s.net>; +Cc: pgsql-performance
On Tue, 29 Apr 2008, Guido Neitzer wrote:
> They totally missed "mainly write" applications which most of my applications
> are.
Not totally--the very first graph shows that even on random data, 100%
write apps are 1/2 the speed of a regular hard drive.
After poking around the site a bit more they also did some tests with MFT,
some kernel software from Easy Computing that basically uses a write log
disk to improve the write situation:
http://www.bigdbahead.com/?p=44
That version also has a better summary of the results.
MFT is clearly not ready for prime time yet from the general buginess, but
as that approach matures (and more vendors do something similar in
hardware) it will be really interesting to see what happens.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: SSD database benchmarks
@ 2008-04-29 23:27 Merlin Moncure <mmoncure@gmail.com>
parent: Greg Smith <gsmith@gregsmith.com>
1 sibling, 0 replies; 4+ messages in thread
From: Merlin Moncure @ 2008-04-29 23:27 UTC (permalink / raw)
To: Greg Smith <gsmith@gregsmith.com>; +Cc: pgsql-performance
On Tue, Apr 29, 2008 at 2:55 PM, Greg Smith <gsmith@gregsmith.com> wrote:
> This is the best write-up I've seen yet on quantifying what SSDs are good
> and bad at in a database context:
>
> http://www.bigdbahead.com/?p=37
>
> --
> * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
here is another really informative article (pdf)
http://www.storagesearch.com/easyco-flashperformance-art.pdf.
The conclusions are different...they claim it's hard to make good use
of ssd advantages if you do any random writing at all. Of course,
they are also developing an automagical solution to the problem. The
information is good though...it's certainly worth a read. The problem
is probably solvable.
merlin
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2008-04-29 23:27 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2008-04-29 18:55 SSD database benchmarks Greg Smith <gsmith@gregsmith.com>
2008-04-29 20:00 ` Guido Neitzer <lists@event-s.net>
2008-04-29 23:26 ` Greg Smith <gsmith@gregsmith.com>
2008-04-29 23:27 ` Merlin Moncure <mmoncure@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox