pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Nicolas Charles <nicolas.charles@normation.com>
To: Neto pr <netopr9@gmail.com>
To: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
Cc: Fernando Hevia <fhevia@gmail.com>
Cc: Georg H. <georg-h@silentrunner.de>
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: HDD vs SSD without explanation
Date: Tue, 16 Jan 2018 16:08:01 +0100
Message-ID: <e6ce9e6e-28cb-9f7d-7421-8f393053808b@normation.com> (raw)
In-Reply-To: <CA+wPC0NBfH0WrG-Zs7BvJ26R+kT2fMowoj_KuhhX2E55v6ZrLw@mail.gmail.com>
References: <CA+wPC0MR7Z0oiOvnenS1TGdU2gOcbSoGMW177jqPJ08DJ=DrCg@mail.gmail.com>
	<0b5a8964-132b-f41f-11d6-5cc6bf0cc551@silentrunner.de>
	<CAGYT1XRgSpEjS6OSYMpER5-33W4ZZXU+C18OWypfEs=GEzUZfQ@mail.gmail.com>
	<CA+wPC0NKKT-n4axOpVT+=hipvU=7uKO7UWZDUgDbWcUNE6n1vw@mail.gmail.com>
	<CAGYT1XRUyRhy3VTb=kzSDiX-NfmDCjwq18F6DpyqtrWJiwiSxw@mail.gmail.com>
	<e568c009-8913-8ccf-1bf4-211832b3b31e@catalyst.net.nz>
	<CA+wPC0NBfH0WrG-Zs7BvJ26R+kT2fMowoj_KuhhX2E55v6ZrLw@mail.gmail.com>

Le 16/01/2018 à 11:14, Neto pr a écrit :
> 2018-01-15 20:04 GMT-08:00 Mark Kirkwood <mark.kirkwood@catalyst.net.nz>:
>> On 16/01/18 13:18, Fernando Hevia wrote:
>>
>>>
>>>
>>> The 6 Gb/s interface is capable of a maximum throughput of around 600
>>> Mb/s. None of your drives can achieve that so I don't think you are limited
>>> to the interface speed. The 12 Gb/s interface speed advantage kicks in when
>>> there are several drives installed and it won't make a diference in a single
>>> drive or even a two drive system.
>>>
>>> But don't take my word for it. Test your drives throughput with the
>>> command Justin suggested so you know exactly what each drive is capable of:
>>>
>>>      Can you reproduce the speed difference using dd ?
>>>      time sudo dd if=/dev/sdX of=/dev/null bs=1M count=32K
>>>      skip=$((128*$RANDOM/32)) # set bs to optimal_io_size
>>>
>>>
>>> While common sense says SSD drive should outperform the mechanical one,
>>> your test scenario (large volume sequential reads) evens out the field a
>>> lot. Still I would have expected somewhat similar results in the outcome, so
>>> yes, it is weird that the SAS drive doubles the SSD performance. That is why
>>> I think there must be something else going on during your tests on the SSD
>>> server. It can also be that the SSD isn't working properly or you are
>>> running an suboptimal OS+server+controller configuration for the drive.
>>>
>> I would second the analysis above - unless you see your read MB/s slammed up
>> against 580-600MB/s contunuously then the interface speed is not the issue.
>> We have some similar servers that we replaced 12x SAS with 1x SATA 6 GBit/s
>> (Intel DC S3710) SSD...and the latter way outperforms the original 12 SAS
>> drives.
>>
>> I suspect the problem is the particular SSD you have - I have benchmarked
>> the 256GB EVO variant and was underwhelmed by the performance. These
>> (budget) triple cell nand SSD seem to have highly variable read and write
>> performance (the write is all about when the SLC nand cache gets
>> full)...read I'm not so sure of - but it could be crappy chipset/firmware
>> combination. In short I'd recommend *not* using that particular SSD for a
>> database workload. I'd recommend one of the Intel Datacenter DC range (FWIW
>> I'm not affiliated with Intel in any way...but their DC stuff works well).
>>
>> regards
>>
>> Mark
> Hi Mark
> In other forums one person said me that on samsung evo should be
> partition aligned to 3072 not  default 2048 , to start on erase block
> bounduary .  And fs block should be 8kb. I am studing this too. Some
> DBAs have reported in other situations that the SSDs when they are
> full, are very slow. Mine is 85% full, so maybe that is also
> influencing. I'm disappointed with this SSD from Samsung, because in
> theory, the read speed of an SSD should be more than 300 times faster
> than an HDD and this is not happening.
>
> regards
> Neto
>
Hi Neto,

Unfortunately, Samsung 850 Evo is not a particularly fast SSD - 
especially it's not really consistent in term of performance ( see 
https://www.anandtech.com/show/8747/samsung-ssd-850-evo-review/5 and 
https://www.anandtech.com/bench/product/1913 ). This is not a product 
for professional usage, and you should not expect great performance from 
it - as reported by these benchmark, you can have a 34ms latency in very 
intensive usage:
ATSB - The Destroyer (99th Percentile Write Latency)99th Percentile 
Latency in Microseconds - Lower is Better *34923

*Even average write latency of the Samsung 850 Evo is 3,3 ms in 
intensive workload, while the HPE 300 GB 12G SAS is reported to have an 
average of 2.9 ms, and won't suffer from write amplification

As long has you stick with a light usage, this SSD will probably be more 
than capable, but if you want to host a database, you should really look 
at PRO drives

Kind regards
Nicolas
**

view thread (22+ messages)  latest in thread

Message-ID: <e6ce9e6e-28cb-9f7d-7421-8f393053808b@normation.com>
Permalink:  ../e6ce9e6e-28cb-9f7d-7421-8f393053808b@normation.com/
Also on:    postgresql.org/message-id/e6ce9e6e-28cb-9f7d-7421-8f393053808b@normation.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: nicolas.charles@normation.com, netopr9@gmail.com, mark.kirkwood@catalyst.net.nz, fhevia@gmail.com, georg-h@silentrunner.de, pgsql-performance@lists.postgresql.org
  Subject: Re: HDD vs SSD without explanation
  In-Reply-To: <e6ce9e6e-28cb-9f7d-7421-8f393053808b@normation.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

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