På onsdag 09. mai 2018 kl. 22:00:16, skrev Andreas Joseph Krogh < andr...@visena.com <mailto:andr...@visena.com>>: På tirsdag 10. april 2018 kl. 19:41:59, skrev Craig James < cja...@emolecules.com <mailto:cja...@emolecules.com>>: On Tue, Apr 10, 2018 at 12:21 AM, Andreas Joseph Krogh <andr...@visena.com <mailto:andr...@visena.com>> wrote: På tirsdag 10. april 2018 kl. 04:36:27, skrev Craig James <cja...@emolecules.com <mailto:cja...@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 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>
