pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedSv: Sv: Re: Latest advice on SSD?
2+ messages / 2 participants
[nested] [flat]
* Sv: Sv: Re: Latest advice on SSD?
@ 2018-05-11 11:23 Andreas Joseph Krogh <andreas@visena.com>
2018-05-11 12:11 ` Re: Sv: Sv: Re: Latest advice on SSD? Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
0 siblings, 1 reply; 2+ messages in thread
From: Andreas Joseph Krogh @ 2018-05-11 11:23 UTC (permalink / raw)
To: pgsql-performance@lists.postgresql.org
På onsdag 09. mai 2018 kl. 22:00:16, skrev Andreas Joseph Krogh <
andreas@visena.com <mailto:andreas@visena.com>>:
På tirsdag 10. april 2018 kl. 19:41:59, skrev Craig James <
cjames@emolecules.com <mailto:cjames@emolecules.com>>:
On Tue, Apr 10, 2018 at 12:21 AM, Andreas Joseph Krogh <andreas@visena.com
<mailto:andreas@visena.com>> wrote: På tirsdag 10. april 2018 kl. 04:36:27,
skrev Craig James <cjames@emolecules.com <mailto:cjames@emolecules.com>>:
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.
With what arguments (also initialization)?
pgbench -i -s 100 -U test
pgbench -U test -c ... -t ...
-c -t TPS
5 20000 5202
10 10000 7916
20 5000 7924
30 3333 7270
40 2500 5020
50 2000 6417
FWIW; We're testing
this: https://www.supermicro.nl/products/system/1U/1029/SYS-1029U-TN10RT.cfm
with 4 x Micron NVMe 9200 PRO NVMe 3.84TB U.2 in RAID-10:
$ pgbench -s 100 -c 64 -t 10000 pgbench
scale option ignored, using count from pgbench_branches table (100)
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 100
query mode: simple
number of clients: 64
number of threads: 1
number of transactions per client: 10000
number of transactions actually processed: 640000/640000
latency average = 2.867 ms
tps = 22320.942063 (including connections establishing)
tps = 22326.370955 (excluding connections establishing)
Sorry, wrong disks; this is correct:
48 clients:
pgbench -s 100 -c 48 -t 10000 pgbench
scale option ignored, using count from pgbench_branches table (100)
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 100
query mode: simple
number of clients: 48
number of threads: 1
number of transactions per client: 10000
number of transactions actually processed: 480000/480000
latency average = 1.608 ms
tps = 29846.511054 (including connections establishing)
tps = 29859.483666 (excluding connections establishing)
64 clients:
pgbench -s 100 -c 64 -t 10000 pgbench
scale option ignored, using count from pgbench_branches table (100)
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 100
query mode: simple
number of clients: 64
number of threads: 1
number of transactions per client: 10000
number of transactions actually processed: 640000/640000
latency average = 2.279 ms
tps = 28077.261708 (including connections establishing)
tps = 28085.730160 (excluding connections establishing)
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andreas@visena.com <mailto:andreas@visena.com>
www.visena.com <https://www.visena.com;
<https://www.visena.com;
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Sv: Sv: Re: Latest advice on SSD?
2018-05-11 11:23 Sv: Sv: Re: Latest advice on SSD? Andreas Joseph Krogh <andreas@visena.com>
@ 2018-05-11 12:11 ` Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
0 siblings, 0 replies; 2+ messages in thread
From: Mark Kirkwood @ 2018-05-11 12:11 UTC (permalink / raw)
To: pgsql-performance@lists.postgresql.org
On 11/05/18 23:23, Andreas Joseph Krogh wrote:
> På onsdag 09. mai 2018 kl. 22:00:16, skrev Andreas Joseph Krogh
> <andreas@visena.com <mailto:andreas@visena.com>>:
>
> På tirsdag 10. april 2018 kl. 19:41:59, skrev Craig James
> <cjames@emolecules.com <mailto:cjames@emolecules.com>>:
>
> On Tue, Apr 10, 2018 at 12:21 AM, Andreas Joseph Krogh
> <andreas@visena.com <mailto:andreas@visena.com>> wrote:
>
> På tirsdag 10. april 2018 kl. 04:36:27, skrev Craig James
> <cjames@emolecules.com <mailto:cjames@emolecules.com>>:
>
> 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.
>
> With what arguments (also initialization)?
>
> pgbench -i -s 100 -U test
> pgbench -U test -c ... -t ...
> -c -t TPS
> 5 20000 5202
> 10 10000 7916
> 20 5000 7924
> 30 3333 7270
> 40 2500 5020
> 50 2000 6417
>
> FWIW; We're testing
> this: https://www.supermicro.nl/products/system/1U/1029/SYS-1029U-TN10RT.cfm
> with 4 x Micron NVMe 9200 PRO NVMe 3.84TB U.2 in RAID-10:
> $ pgbench -s 100 -c 64 -t 10000 pgbench
> scale option ignored, using count from pgbench_branches table (100)
> starting vacuum...end.
> transaction type: <builtin: TPC-B (sort of)>
> scaling factor: 100
> query mode: simple
> number of clients: 64
> number of threads: 1
> number of transactions per client: 10000
> number of transactions actually processed: 640000/640000
> latency average = 2.867 ms
> tps = 22320.942063 (including connections establishing)
> tps = 22326.370955 (excluding connections establishing)
>
> Sorry, wrong disks; this is correct:
> 48 clients:
> pgbench -s 100 -c 48 -t 10000 pgbench
> scale option ignored, using count from pgbench_branches table (100)
> starting vacuum...end.
> transaction type: <builtin: TPC-B (sort of)>
> scaling factor: 100
> query mode: simple
> number of clients: 48
> number of threads: 1
> number of transactions per client: 10000
> number of transactions actually processed: 480000/480000
> latency average = 1.608 ms
> tps = 29846.511054 (including connections establishing)
> tps = 29859.483666 (excluding connections establishing)
> 64 clients:
> pgbench -s 100 -c 64 -t 10000 pgbench
> scale option ignored, using count from pgbench_branches table (100)
> starting vacuum...end.
> transaction type: <builtin: TPC-B (sort of)>
> scaling factor: 100
> query mode: simple
> number of clients: 64
> number of threads: 1
> number of transactions per client: 10000
> number of transactions actually processed: 640000/640000
> latency average = 2.279 ms
> tps = 28077.261708 (including connections establishing)
> tps = 28085.730160 (excluding connections establishing)
>
If I'm doing the math properly, then these runs are very short (i.e
about 20s). It would be interesting to specify a time limit (e.g -T600
or similar) so we see the effect of at least one checkpoint - i.e the
disks are actually forced to write and sync the transaction data.
These Micron disks look interesting (pretty good IOPS and lifetime
numbers). However (as usual with Micron, sadly) no data about power off
safety. Do you know if the the circuit board has capacitors?
regards
Mark
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2018-05-11 12:11 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-05-11 11:23 Sv: Sv: Re: Latest advice on SSD? Andreas Joseph Krogh <andreas@visena.com>
2018-05-11 12:11 ` Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
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