Re: Optimal settings for RAID controller - optimized for writes - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: Optimal settings for RAID controller - optimized for writes
Date
Msg-id CAHyXU0zr2jOZb-_FQuVXCbk+1z5WD3+Fg_z_uNo_SFBT5Vp3Tg@mail.gmail.com
Whole thread Raw
In response to Re: Optimal settings for RAID controller - optimized for writes  (Scott Marlowe <scott.marlowe@gmail.com>)
List pgsql-performance
On Wed, Feb 19, 2014 at 12:09 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
> On Wed, Feb 19, 2014 at 8:13 AM, Merlin Moncure <mmoncure@gmail.com> 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.
>>
>> 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.
>
> You can also do the old trick of underprovisioning and / or
> underutilizing all the space on SSDs. I.e. put 10 600GB SSDs under a
> HW RAID controller in RAID-10, then only parititon out 1/2 the storage
> you get from that. so you get 1.5TB os storage and the drives are
> underutilized enough to have spare space.
>
> Right now I'm testing on a machine with 2x Intel E5-2690s
> (http://ark.intel.com/products/64596/intel-xeon-processor-e5-2690-20m-cache-2_90-ghz-8_00-gts-intel-qpi)
> 512GB RAM and 6x600GB Intel SSDs (not sure which ones) under a LSI
> MegaRAID 9266. I'm able to crank out 6500 to 7200 TPS under pgbench on
> a scale 1000 db at 8 to 60 clients on that machine. It's not cheap,
> but storage wise it's WAY cheaper than most SANS and very fast.
> pg_xlog is on a pair of non-descript SATA spinners btw.

Yeah -- underprovisioing certainly helps but for any write heavy
configuration, all else being equal, TRIM support will perform faster
and have less wear.  Those drives are likely the older 320 600gb.  The
newer s3700 are much faster although they cost around twice as much.

merlin


pgsql-performance by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Optimal settings for RAID controller - optimized for writes
Next
From: Tomas Vondra
Date:
Subject: Re: Optimal settings for RAID controller - optimized for writes