Re: Tip: Your next XRaid may be an SSD
Re: Tip: Your next XRaid may be an SSD
- Subject: Re: Tip: Your next XRaid may be an SSD
- From: "Pierce T. Wetter III" <email@hidden>
- Date: Mon, 15 Dec 2008 22:24:33 -0700
On Dec 15, 2008, at 5:10 PM, Guido Neitzer wrote:
On 15.12.2008, at 15:27, Miguel Arroz wrote:
Excellent email! I've been arguing for some time now that SSD is
the way to go for DBs, it's good that some real evidence is showing
up. Seek time kills DBs. :)
There is some evidence showing up, true, but it also probably shows
bad cache strategies or usage patterns resulting in bad hit rate on
the cache.
If a change from HD to SSD results in a 40x increase in query
performance, something seems to be badly wrong with what the
database does - or the usage pattern and / or the database setup is
not optimal.
It also might be a case where FrontBase hits some bad walls due to
what it does while other databases will be not nearly as badly
effected. For example lots of inserts into large tables with a
couple indexes plain kills FrontBase performance (at least up to
version 4.x).
So, these values might be valid for FrontBase, but need a careful
look where the real gain is coming from as a fast RAID (I'm not
talking about XserveRAID obviously) combined with a working cache
will deliver a very high performance, too. Especially when writing
to the disks.
Well, there are a couple of issues unique to our data set.
First, realize, that its not a perfect apples/oranges comparison,
because I didn't run the SQL test on our Production XRaid, but rather
on my local hard disk. (Because, well, the XRaid is busy. :-) ) If
you look at the XBench stats for Random Read/Writes, you can see that
the RAID does pretty well, it's 28 times faster on writes then a
single HDD, so that would mean the SSD is only 4x faster instead of
93x for that stat. But still, 4x is nothing to sneeze at.
Next, we have a high write/read ratio. So we're fundamentally
limited by Random/Write speed, because that has to get flushed to disk
(though actually in FB, only the Tlog has to be flushed for the commit
to work). A lot of the SQL is basically saving a bunch of log file
messages. So that data can't be cached.
Also it was a freshly started database in all cases, so the row
and disk caches probably weren't stabilized yet.
So yeah, there are a whole bunch of things that databases do to
take advantage of the 80/20 rule. But remember, this is the
performance of a single drive, and its kicking butt.
Pierce
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden