Sv: Sv: Re: Latest advice on SSD?

2018-05-11 Thread Andreas Joseph Krogh 
På onsdag 09. mai 2018 kl. 22:00:16, skrev Andreas Joseph Krogh <
[email protected] >:
På tirsdag 10. april 2018 kl. 19:41:59, skrev Craig James <
[email protected] >:
    On Tue, Apr 10, 2018 at 12:21 AM, Andreas Joseph Krogh mailto:[email protected]>> wrote: På tirsdag 10. april 2018 kl. 04:36:27, 
skrev Craig James mailto:[email protected]>>:
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   2  5202
10  1  7916
20  5000   7924
30     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 1 pgbench
 scale option ignored, using count from pgbench_branches table (100)
 starting vacuum...end.
 transaction type: 
 scaling factor: 100
 query mode: simple
 number of clients: 64
 number of threads: 1
 number of transactions per client: 1
 number of transactions actually processed: 64/64
 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 1 pgbench 
 scale option ignored, using count from pgbench_branches table (100)
 starting vacuum...end.
 transaction type: 
 scaling factor: 100
 query mode: simple
 number of clients: 48
 number of threads: 1
 number of transactions per client: 1
 number of transactions actually processed: 48/48
 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 1 pgbench 
 scale option ignored, using count from pgbench_branches table (100)
 starting vacuum...end.
 transaction type: 
 scaling factor: 100
 query mode: simple
 number of clients: 64
 number of threads: 1
 number of transactions per client: 1
 number of transactions actually processed: 64/64
 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
[email protected] 
www.visena.com 
 


 

Re: Sv: Sv: Re: Latest advice on SSD?

2018-05-11 Thread Mark Kirkwood 

On 11/05/18 23:23, Andreas Joseph Krogh wrote:

På onsdag 09. mai 2018 kl. 22:00:16, skrev Andreas Joseph Krogh 
mailto:[email protected]>>:


På tirsdag 10. april 2018 kl. 19:41:59, skrev Craig James
mailto:[email protected]>>:

On Tue, Apr 10, 2018 at 12:21 AM, Andreas Joseph Krogh
mailto:[email protected]>> wrote:

På tirsdag 10. april 2018 kl. 04:36:27, skrev Craig James
mailto:[email protected]>>:

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   2  5202
10  1  7916
20  5000   7924
30     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 1 pgbench
scale option ignored, using count from pgbench_branches table (100)
starting vacuum...end.
transaction type: 
scaling factor: 100
query mode: simple
number of clients: 64
number of threads: 1
number of transactions per client: 1
number of transactions actually processed: 64/64
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 1 pgbench
scale option ignored, using count from pgbench_branches table (100)
starting vacuum...end.
transaction type: 
scaling factor: 100
query mode: simple
number of clients: 48
number of threads: 1
number of transactions per client: 1
number of transactions actually processed: 48/48
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 1 pgbench
scale option ignored, using count from pgbench_branches table (100)
starting vacuum...end.
transaction type: 
scaling factor: 100
query mode: simple
number of clients: 64
number of threads: 1
number of transactions per client: 1
number of transactions actually processed: 64/64
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

Sv: Re: Sv: Sv: Re: Latest advice on SSD?

2018-05-11 Thread Andreas Joseph Krogh 
På fredag 11. mai 2018 kl. 14:11:39, skrev Mark Kirkwood <
[email protected] >:
On 11/05/18 23:23, Andreas Joseph Krogh wrote:

 > På onsdag 09. mai 2018 kl. 22:00:16, skrev Andreas Joseph Krogh
 > mailto:[email protected]>>:
 >
 >     På tirsdag 10. april 2018 kl. 19:41:59, skrev Craig James
 >     mailto:[email protected]>>:
 >
 >         On Tue, Apr 10, 2018 at 12:21 AM, Andreas Joseph Krogh
 >         mailto:[email protected]>> wrote:
 >
 >             På tirsdag 10. april 2018 kl. 04:36:27, skrev Craig James
 >             mailto:[email protected]>>:
 >
 >                 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   2  5202
 >         10  1  7916
 >         20  5000   7924
 >         30     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 1 pgbench
 >     scale option ignored, using count from pgbench_branches table (100)
 >     starting vacuum...end.
 >     transaction type: 
 >     scaling factor: 100
 >     query mode: simple
 >     number of clients: 64
 >     number of threads: 1
 >     number of transactions per client: 1
 >     number of transactions actually processed: 64/64
 >     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 1 pgbench
 > scale option ignored, using count from pgbench_branches table (100)
 > starting vacuum...end.
 > transaction type: 
 > scaling factor: 100
 > query mode: simple
 > number of clients: 48
 > number of threads: 1
 > number of transactions per client: 1
 > number of transactions actually processed: 48/48
 > 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 1 pgbench
 > scale option ignored, using count from pgbench_branches table (100)
 > starting vacuum...end.
 > transaction type: 
 > scaling factor: 100
 > query mode: simple
 > number of clients: 64
 > number of threads: 1
 > number of transactions per client: 1
 > number of transactions actually processed: 64/64
 > 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
 
$ pgbench -s 100 -c 64 -T600 pgbench
 scale option ignored, using count from pgbench_branches table (100)
 starting vacuum...end.
 transaction type: 
 scaling factor: 100
 query mode: simple
 number of clients: 64
 number of threads: 1
 duration: 600 s
 number of transactions actually processed: 16979208
 latency average = 2.262 ms
 tps = 28298.582988 (including connections establishing)
 tps = 28298.926331 (excluding connections establishing)
  
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56

Sv: Re: Sv: Sv: Re: Latest advice on SSD?

2018-05-11 Thread Andreas Joseph Krogh 
På fredag 11. mai 2018 kl. 14:11:39, skrev Mark Kirkwood <
[email protected] >:
[snip]
 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?
 
Don't know, sorry...
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
[email protected] 
www.visena.com 
 


 

Re: Latest advice on SSD?

2018-05-11 Thread Evgeniy Shishkin 


> On May 11, 2018, at 15:11, Mark Kirkwood  
> wrote:
> 
> On 11/05/18 23:23, Andreas Joseph Krogh wrote:
> 
>> På onsdag 09. mai 2018 kl. 22:00:16, skrev Andreas Joseph Krogh 
>> mailto:[email protected]>>:
>> 
>>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:
>>
> 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?

According to 
https://www.micron.com/~/media/documents/products/data-sheet/ssd/9200_u_2_pcie_ssd.pdf
 


The SSD supports an unexpected power loss with a power-backed write cache. No 
userdata is lost during an unexpected power loss. When power is subsequently 
restored, theSSD returns to a ready state within a maximum of 60 seconds.

Re: Latest advice on SSD?

2018-05-11 Thread Mark Kirkwood 

On 12/05/18 02:48, Evgeniy Shishkin wrote:




On May 11, 2018, at 15:11, Mark Kirkwood 
> wrote:


On 11/05/18 23:23, Andreas Joseph Krogh wrote:

På onsdag 09. mai 2018 kl. 22:00:16, skrev Andreas Joseph Krogh 
mailto:[email protected]> 
>:


   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:
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?


According to 
https://www.micron.com/~/media/documents/products/data-sheet/ssd/9200_u_2_pcie_ssd.pdf 



The SSD supports an unexpected power loss with a power-backed write 
cache. No userdata is lost during an unexpected power loss. When power 
is subsequently restored, theSSD returns to a ready state within a 
maximum of 60 seconds.


Excellent, and thanks for finding the details - note the document 
explicitly states that they have capacitor backed power loss protection. 
So looking good as a viable alternative to Intel's S4500, S4600, P4500, 
P4600 range. One point to note - we've been here before with Micron 
claiming power loss protection and having to retract it later (Crucial 
M550 range...I have 2 of these BTW) - but to be fair to Micron the 
Crucial range is purely consumer and this Micron 9200 is obviously an 
enterprise targeted product. But some power loss testing might be advised!


Cheers
Mark