[Cialug] SDD drives (again)

[Matthew Nuzum]

On Wed, Feb 29, 2012 at 6:14 PM, Dave Hala Jr <dave at 58ghz.net> wrote:

> Its the seek time. Personally, I think its easier to manage the VM if
> everything is contained (for lack of a better word) in one container.
>

Writes or Reads?

Now days the answer is often SSD but there are two other options to keep on
your radar.

If the data is largely reads, can you fit the necessary tables into RAM? If
so, then there are a few ways to accomplish this, one is to warm up the
database by selecting every record before you do your reporting (and
getting it into the OS's disk cache) or by using whatever trick your
database supports to mirror the db into a ram disk.

If the data is a lot of writes then you can try adding two drives and doing
RAID 10. Considering the modest size requirements you need this may not be
cheaper than a 120G SSD.

Since you describe the problem as seek related I'd seriously look into the
first option, loading the data into RAM. If you have enough that will yield
far better performance than even SSDs. You may not need the whole db in
RAM. (Using postgresql as an example) you can add an "EXPLAIN ANALYZE"
before your slow select queries to see what is slowing things down. This
will tip you off to what data needs to be warmed up.

Other tricks I've used in the past were to partition the drive so that only
the outer edges of the disk were used. The data density at the outer edge
is higher so you have less head movement (and faster seek time). By density
I mean that more data travels under the read head with one rotation. Also,
in a RAID 10 setup, adjusting the block size of the stripes to be bigger
(say 256K).

Anyway, if you'd rather put your time into it than your money there are a
number of tricks available to you. Getting more of your data into RAM is
not too hard and for read-heavy loads there is nothing better.

-- 
Matthew Nuzum
newz2000 on freenode, skype, linkedin and twitter

♫ You're never fully dressed without a smile! ♫