Re: RAID and SSD configuration question - Mailing list pgsql-general

From Scott Marlowe
Subject Re: RAID and SSD configuration question
Date
Msg-id CAOR=d=0DcSaHHt+6SyGwCG0KqHB+U4XgiE8TMbui2qontyKvOQ@mail.gmail.com
Whole thread Raw
In response to Re: RAID and SSD configuration question  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: RAID and SSD configuration question
List pgsql-general
> On Tue, Oct 20, 2015 at 9:33 AM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>> We're running LSI MegaRAIDs at work with 10 SSD RAID-5 arrays, and we
>> can get ~5k to 7k tps on a -s 10000 pgbench with the write cache on.
>>
>> When we turn the write cache off, we get 15k to 20k tps. This is on a
>> 120GB pgbench db that fits in memory, so it's all writes.
>
> This is my findings exactly.  I'll double down on my statement;
> caching raid controllers are essentially obsolete technology.  They
> are designed to solve a problem that simply doesn't exist any more
> because of SSDs.  Unless your database is very, very, busy it's pretty
> hard to saturate a single low-mid tier SSD with zero engineering
> effort.  It's time to let go:  spinning drives are obsolete in the
> database world, at least in any scenario where you're measuring IOPS.

Here's what's REALLY messed up. The older the firmware on the
megaraid, the faster it ran with caching on. We had 3 to 4 year old
firmware and were getting 7 to 8k tps. As we upgraded firmware it got
all the way down to 3k tps, then the very latest got it back up to 4k
or so. No matter what version of the firmware, turning off caching got
us to 15 to 18k easy. So it appears more aggressive and complex
caching algorithms just made things worse and worse.


pgsql-general by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: My first PL/pgSQL function
Next
From: Dane Foster
Date:
Subject: Re: My first PL/pgSQL function