From: Tomas Vondra <tv@fuzzy.cz>
To: pgsql-performance@postgresql.org
Subject: Re: Optimal settings for RAID controller - optimized for writes
Date: Thu, 20 Feb 2014 01:26:43 +0100
Message-ID: <53054BC3.2000106@fuzzy.cz> (raw)
In-Reply-To: <CAHyXU0x6koA5UwHqNpJOP09DFvJsp73Rar-3gkbz1UjbYRQCtg@mail.gmail.com>
References: <D89BE95F-60D2-431B-A82D-53378392AAC3@autouncle.com>
<CALqvQ1MRopjqc3W8Q_U061Lmm04Eip65cDNtfqB6mhj0wbA94g@mail.gmail.com>
<bc5e841fac96910a36a563e844dfb80a.squirrel@sq.gransy.com>
<5302B5FD.10204@lab.ntt.co.jp>
<5303C573.8@fuzzy.cz>
<CAHyXU0x6koA5UwHqNpJOP09DFvJsp73Rar-3gkbz1UjbYRQCtg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On 19.2.2014 16:13, Merlin Moncure wrote:
> On Tue, Feb 18, 2014 at 2:41 PM, Tomas Vondra <tv@fuzzy.cz> wrote:
>> On 18.2.2014 02:23, KONDO Mitsumasa wrote:
>>> Hi,
>>>
>>> I don't have PERC H710 raid controller, but I think he would like to
>>> know raid striping/chunk size or read/write cache ratio in
>>> writeback-cache setting is the best. I'd like to know it, too:)
>>
>> We do have dozens of H710 controllers, but not with SSDs. I've been
>> unable to find reliable answers how it handles TRIM, and how that works
>> with wearout reporting (using SMART).
>
> AFAIK (I haven't looked for a few months), they don't support TRIM.
> The only hardware RAID vendor that has even basic TRIM support Intel
> and that's no accident; I have a theory that enterprise storage
> vendors are deliberately holding back SSD: SSD (at least, the newer,
> better ones) destroy the business model for "enterprise storage
> equipment" in a large percentage of applications. A 2u server with,
> say, 10 s3700 drives gives *far* superior performance to most SANs
> that cost under 100k$. For about 1/10th of the price.
Yeah, maybe. I'm generally a bit skeptic when it comes to conspiration
theories like this, but for ~1 year we all know that it might easily
happen to be true. So maybe ...
Nevertheless, I'd guess this is another case of the "Nobody ever got
fired for buying X", where X is a storage product based on spinning
drives, proven to be reliable, with known operational statistics and
pretty good understanding of how it works. While "Y" is a new thing
based on SSDs, that got rather bad reputation initially because of a
hype and premature usage of consumer-grade products for unsuitable
stuff. Also, each vendor of Y uses different tricks, which makes
application of experiences across vendors (or even various generations
of drives of the same vendor) very difficult.
Factor in how conservative DBAs happen to be, and I think it might be
this particular feedback loop, forcing the vendors not to push this.
> If you have a server that is i/o constrained as opposed to storage
> constrained (AKA: a database) hard drives make zero economic sense.
> If your vendor is jerking you around by charging large multiples of
> market rates for storage and/or disallowing drives that actually
> perform well in their storage gear, choose a new vendor. And consider
> using software raid.
Yeah, exactly.
Tomas
--
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: tv@fuzzy.cz
Subject: Re: Optimal settings for RAID controller - optimized for writes
In-Reply-To: <53054BC3.2000106@fuzzy.cz>
* 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