Re: SSD performance - Mailing list pgsql-performance

From Craig Ringer
Subject Re: SSD performance
Date
Msg-id 4979CB11.1070800@postnewspapers.com.au
Whole thread Raw
In response to Re: SSD performance  (Luke Lonergan <LLonergan@greenplum.com>)
Responses Re: SSD performance  (Florian Weimer <fweimer@bfk.de>)
Re: SSD performance  (James Mansion <james@mansionfamily.plus.com>)
List pgsql-performance
Luke Lonergan wrote:
> Why not simply plug your server into a UPS and get 10-20x the performance using the same approach (with OS IO cache)?

A big reason is that your machine may already have as much RAM as is
currently economical to install. Hardware with LOTS of RAM slots can
cost quite a bit.

Another reason is that these devices won't lose data because of an
unexpected OS reboot. If they're fitted with a battery backup and CF
media for emergency write-out, they won't lose data if your UPS runs out
of juice either.

I'd be much more confident with something like those devices than I
would with an OS ramdisk plus startup/shutdown scripts to initialize it
from a file and write it out to a file. Wouldn't it be a pain if the UPS
didn't give the OS enough warning to write the RAM disk out before
losing power...

In any case, you're very rarely better off dedicating host memory to a
ramdisk rather than using the normal file system and letting the host
cache it. A ramdisk really only seems to help when you're really using
it to bypass safeties like the effects of fsync() and ordered
journaling. There are other ways to avoid those if you really don't care
about your data.

These devices would be interesting for a few uses, IMO. One is temp
table space and sort space in Pg. Another is scratch space for apps
(like Photoshop) that do their own VM management. There's also potential
for use as 1st priority OS swap space, though at least on Linux I think
the CPU overhead involved in swapping is so awful you wouldn't benefit
from it much.

I've been hoping this sort of thing would turn up again in a new
incarnation with battery backup and CF/SD for BBU-flat safety.

--
Craig Ringer

pgsql-performance by date:

Previous
From: Luke Lonergan
Date:
Subject: Re: SSD performance
Next
From: Florian Weimer
Date:
Subject: Re: SSD performance