Subject: Re: Very poor read performance, query independent
To: Charles Nadeau <charles.nadeau@gmail.com>
Cc: "pgsql-performa." <pgsql-performance@postgresql.org>
References: 
 <CADFyZw7aGoD0AaStxdyHByR5Qta=M5wx0v=iptKLhPUp+EOKvA@mail.gmail.com>
 <dc5d2b63-0a1b-ff76-c88a-87c2c41bd5b8@a-kretschmer.de>
 <CADFyZw4UanW5TbFajWKWhN9XcW+8gtCXw+kssHo47Wpr1A=zJw@mail.gmail.com>
 <DM5PR07MB28103FD558CB6628CECE07BEDAA90@DM5PR07MB2810.namprd07.prod.outlook.com>
 <CADFyZw6JrhsLR_eYOeCjjiQMzz5bepk6AfMRBu0hnaQg+vN-=A@mail.gmail.com>
 <a8fa0c8a-1269-338e-80a6-cb121574be7c@catalyst.net.nz>
 <CADFyZw5-WzdkACN39-ND9tvBwmvfdEhFaYL3Ds82a3Rwav-neA@mail.gmail.com>
 <fc07e0b4-0a24-bd29-e9f2-b75947cbf82b@catalyst.net.nz>
 <dadb1945-062f-c565-26ee-d334898d7cf5@catalyst.net.nz>
 <CADFyZw579_W96dD_beduHeCFomVg1Xe8P+Kpi6jq3Z8+GsYVjw@mail.gmail.com>
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
Message-ID: <fbcf5e69-baa2-f123-2e8b-844a2c534785@catalyst.net.nz>
Date: Sat, 19 Aug 2017 18:51:34 +1200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
 <CADFyZw579_W96dD_beduHeCFomVg1Xe8P+Kpi6jq3Z8+GsYVjw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Nice!

Pleased that the general idea worked well for you!

I'm also relieved that you did not follow my recommendation exactly - 
I'm been trialling a Samsung 960 Evo (256GB) and Intel 600p (256GB) and 
I've stumbled across the serious disadvantages of (consumer) M.2 drives 
using TLC NAND - terrible sustained write performance! While these guys 
can happily do ~ 2GB/s reads, their write performance is only 'burst 
capable'. They have small SLC NAND 'write caches' that do  ~1GB/s for a 
*limited time* (10-20s) and after that you get ~ 200 MB/s! Ouch - my old 
Crucial 550 can do 350 MB/s sustained writes (so two of them in RAID0 
are doing 700 MB/s for hours).

Bigger capacity drives can do better - but overall I'm not that 
impressed with the current trend of using TLC NAND.

regards

Mark


On 21/07/17 00:50, Charles Nadeau wrote:
> Mark,
>
> I received yesterday a second server having 16 drives bays. Just for a 
> quick trial, I used 2 old 60GB SSD (a Kingston V300 and a ADATA SP900) 
> to build a RAID0. To my surprise, my very pecky RAID controller (HP 
> P410i) recognised them without a fuss (although as SATAII drives at 
> 3Gb/s. A quick fio benchmark gives me 22000 random 4k read IOPS, more 
> than my 5 146GB 10k SAS disks in RAID0). I moved my most frequently 
> used index to this array and will try to do some benchmarks.
> Knowing that SSDs based on SandForce-2281 controller are recognised by 
> my server, I may buy a pair of bigger/newer ones to put my tables on.
>
> Thanks!
>
> Charles
>
> On Sat, Jul 15, 2017 at 1:57 AM, Mark Kirkwood 
> <mark.kirkwood@catalyst.net.nz <mailto:mark.kirkwood@catalyst.net.nz>> 
> wrote:
>
>     Thinking about this a bit more - if somewhat more blazing
>     performance is needed, then this could be achieved via losing the
>     RAID card and spinning disks altogether and buying 1 of the NVME
>     or SATA solid state products: e.g
>
>     - Samsung 960 Pro or Evo 2 TB (approx 1 or 2 GB/s seq scan speeds
>     and 200K IOPS)
>
>     - Intel S3610 or similar 1.2 TB (500 MB/s seq scan and 30K IOPS)
>
>
>     The Samsung needs an M.2 port on the mobo (but most should have
>     'em - and if not PCIe X4 adapter cards are quite cheap). The Intel
>     is a bit more expensive compared to the Samsung, and is slower but
>     has a longer lifetime. However for your workload the Sammy is
>     probably fine.
>
>     regards
>
>     Mark
>
>     On 15/07/17 11:09, Mark Kirkwood wrote:
>
>         Ah yes - that seems more sensible (but still slower than I
>         would expect for 5 disks RAID 0).
>
>
>
>
>     -- 
>     Sent via pgsql-performance mailing list
>     (pgsql-performance@postgresql.org
>     <mailto:pgsql-performance@postgresql.org>)
>     To make changes to your subscription:
>     http://www.postgresql.org/mailpref/pgsql-performance
>     <http://www.postgresql.org/mailpref/pgsql-performance>
>
>
>
>
> -- 
> Charles Nadeau Ph.D.
> http://charlesnadeau.blogspot.com/


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance