Re: Latest advice on SSD? - Mailing list pgsql-performance

From Matthew Hall
Subject Re: Latest advice on SSD?
Date
Msg-id 45F04B78-1877-4628-A758-2ABE0C57BA7C@mhcomputing.net
Whole thread Raw
In response to Latest advice on SSD?  (Craig James <cjames@emolecules.com>)
Responses Re: Latest advice on SSD?  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
List pgsql-performance
The most critical bit of advice I've found is setting this preference:


I'm using 4 512GB Samsung 850 EVOs in a hardware RAID 10 on a 1U server with about 144 GB RAM and 8 Xeon cores. I usually burn up CPU more than I burn up disks or RAM as compared to using magnetic where I had horrible IO wait percentages, so it seems to be performing quite well so far. 

Matthew Hall

On Apr 9, 2018, at 7:36 PM, Craig James <cjames@emolecules.com> wrote:

One of our four "big iron" (spinning disks) servers went belly up today. (Thanks, Postgres and pgbackrest! Easy recovery.) We're planning to move to a cloud service at the end of the year, so bad timing on this. We didn't want to buy any more hardware, but now it looks like we have to.

I followed the discussions about SSD drives when they were first becoming mainstream; at that time, the Intel devices were king. Can anyone recommend what's a good SSD configuration these days? I don't think we want to buy a new server with spinning disks.

We're replacing:
  8 core (Intel)
  48GB memory
  12-drive 7200 RPM 500GB
     RAID1 (2 disks, OS and WAL log)
     RAID10 (8 disks, postgres data dir)
     2 spares
  Ubuntu 16.04
  Postgres 9.6

The current system peaks at about 7000 TPS from pgbench.

Our system is a mix of non-transactional searching (customers) and transactional data loading (us).

Thanks!
Craig

--
---------------------------------
Craig A. James
Chief Technology Officer
eMolecules, Inc.
---------------------------------

pgsql-performance by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Latest advice on SSD?
Next
From: Adam Brusselback
Date:
Subject: Re: [PERFORM] Dissuade the use of exclusion constraint index