From: Shaun Thomas <sthomas@optionshouse.com>
To: Greg Smith <greg@2ndQuadrant.com>
Cc: Merlin Moncure <mmoncure@gmail.com>
Cc: Tomas Vondra <tv@fuzzy.cz>
Cc: pgsql-performance@postgresql.org
Subject: Re: Reliability with RAID 10 SSD and Streaming Replication
Date: Wed, 22 May 2013 13:28:02 -0500
Message-ID: <519D0E32.20808@optionshouse.com> (raw)
In-Reply-To: <519D0921.9080807@2ndQuadrant.com>
References: <CAAE-9WHMycEZOB5J6HKME5AZLEdL2hYF+FV8hzbLksJinq=EJg@mail.gmail.com>
<51957499.6050905@fuzzy.cz>
<519991EB.8010208@2ndQuadrant.com>
<519A8E29.60702@fuzzy.cz>
<CAHyXU0wvW-USgbkXAYEHLG2fHgj=UdZi1aCFoVWBMQEsOFZy+A@mail.gmail.com>
<519C0EFD.9080002@2ndQuadrant.com>
<CAHyXU0ymFT7Sqw77yPryGWKEpjV4Wv9Vkc21vGtPKo0GZWGg8A@mail.gmail.com>
<519CF8CC.1030204@optionshouse.com>
<519D0921.9080807@2ndQuadrant.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On 05/22/2013 01:06 PM, Greg Smith wrote:
> There's a corresponding price hit though, and
> having to provision PCI-E cards is a pain in some systems.
Oh, totally. Specialist devices like RAMSAN, FusionIO, Virident, or
Whiptail are hideously expensive, even compared to high-end SSDs. I was
just pointing out out that the technical limitations of the underlying
chips (NVRAM) can be overcome or augmented in ways Intel isn't doing (yet).
> 1800 TPS to 20K TPS is just over a 10X speedup.
True. But in that case, it was a single device pitted against 8 very
high-end 15k RPM spindles. I'd need 80-100 drives in a massive SAN to
get similar numbers, and at that point, we're not really saving any
money and have a lot more failure points and maintenance.
I guess you get way more space, though. :)
> The larger units have more channels of flash going at the
> same time. FusionIO has architected such that there is a wide write
> path even on their smallest cards.
Yep. And I've been watching these technologies like a hawk waiting for
the new chips and their performance profiles. Some of the newer chips
have performance multipliers even on a single die in the larger sizes.
> I can buy a good number of Intel DC S3700 drives for what a FusionIO
> card costs though.
I know. :(
But knowing the performance they can deliver, I often dream of a perfect
device comprised of several PCIe-based NVRAM cards in a hot-swap PCIe
enclosure (they exist!). Something like that in a 3U piece of gear would
absolutely annihilate even the largest SAN.
At the mere cost of a half million or so. :p
> I have some moderately fast SSD based transactional systems that are
> still using traditional drives with battery-backed cache for the
> sequential writes of the WAL volume, where the data volume is on
> Intel 710 disks.
That sounds like a very sane and recommendable approach, and
coincidentally the same we would use if we couldn't afford the FusionIO
drives.
I'm actually curious to see how using ZFS with its CoW profile and using
a bundle of SSDs as a ZIL would compare. It's still disk-based, but the
transparent SSD layer acting as a gigantic passive read and write cache
intrigue me. It seems like it would also make a good middle-ground
concerning cost vs. performance.
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-676-8870
sthomas@optionshouse.com
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: sthomas@optionshouse.com, greg@2ndQuadrant.com, mmoncure@gmail.com, tv@fuzzy.cz
Subject: Re: Reliability with RAID 10 SSD and Streaming Replication
In-Reply-To: <519D0E32.20808@optionshouse.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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