Hi Neto,
In a great piece of timing my new experimental SSD arrived (WD Black 500
G 3D NAND MVME) [1]. Doing some runs of query 9:
- default config: 7 minutes
- work_mem=1G, max_parallel_workers_per_gather=4: 3-4 minutes
Increasing either of these much more got me OOM errors (16 G of ram).
And perhaps more interesting:
Re-running query 9 against the (single) HDD setup *but* with pgsql_tmp
symlinked to the 2x SSD RAID0: 15 minutes
I'm thinking that you have inadvertently configured your HDD test in
this way (you get 9 minutes because you have 2x HDDs). Essentially most
of the t
FWIW:
re-running query 9 using the SSD setup as 2x crucial M550 RAID0: 10 minutes.
On 20/07/18 11:30, Mark Kirkwood wrote:
One more thought on this:
Query 9 does a lot pf sorting to disk - so there will be writes for
that and all the reads for the table scans. Thus the location of your
inst
One more thought on this:
Query 9 does a lot pf sorting to disk - so there will be writes for that
and all the reads for the table scans. Thus the location of your
instance's pgsql_tmp directory(s) will significantly influence results.
I'm wondering if in your HDD test the pgsql_tmp on the *S
>Model: 850 Evo 500 GB SATA III 6Gb/s -
please check the SSD *"DRIVE HEALTH STATUS"* and the* "S.M.A.R.T values of
specified disk" *
for example - with the "smartctl" tool ( https://www.smartmontools.org/
) ( -x "Show all information for device" )
Expected output with "Samsung SSD 850 EVO
On Wed, 18 Jul 2018 09:46:32 +0200, Fabio Pardi
wrote:
RAID 0 to store production data should never be used. Never a good
idea, in my opinion.
RAID 0 by itself should never be used. Combined with other RAID
levels, it can boost performance without sacrificing reliability.
https://en.wiki
Ok, so you are using 1 instance and tablespaces. Also I see you are
restarting the instance between HDD and SSD tests, so all good there.
The point I made about having the OS on the SSD's means that if these
tests make your system swap, and your swap device is on the SSDs (which
is probably is
Le 18/07/2018 à 03:16, Neto pr a écrit :
2018-07-17 22:13 GMT-03:00 Neto pr :
2018-07-17 20:04 GMT-03:00 Mark Kirkwood :
Ok, so dropping the cache is good.
How are you ensuring that you have one test setup on the HDDs and one on the
SSDs? i.e do you have 2 postgres instances? or are you using
Hi Neto,
RAID 0 to store production data should never be used. Never a good idea, in my
opinion.
Simple reason is that when you lose one disk, you lose everything.
If your goal is to bench the disk, go for single disk.
If you want to be closer to a production setup, go for RAID 10, or pick a R
2018-07-17 11:43 GMT-03:00 Fabio Pardi :
>
>
> On 07/17/2018 04:05 PM, Neto pr wrote:
>> 2018-07-17 10:55 GMT-03:00 Fabio Pardi :
>
>>> Also i think it makes not much sense testing on RAID 0. I would start
>>> performing tests on a single disk, bypassing RAID (or, as mentioned, at
>>> least disabli
2018-07-17 22:13 GMT-03:00 Neto pr :
> 2018-07-17 20:04 GMT-03:00 Mark Kirkwood :
>> Ok, so dropping the cache is good.
>>
>> How are you ensuring that you have one test setup on the HDDs and one on the
>> SSDs? i.e do you have 2 postgres instances? or are you using one instance
>> with tablespaces
2018-07-17 20:04 GMT-03:00 Mark Kirkwood :
> Ok, so dropping the cache is good.
>
> How are you ensuring that you have one test setup on the HDDs and one on the
> SSDs? i.e do you have 2 postgres instances? or are you using one instance
> with tablespaces to locate the relevant tables? If the 2nd c
Yeah,
A +1 to telling us the model. In particular the later EVOs use TLC nand
with a small SLC cache... and when you exhaust the SLC cache the
performance can be worse than a HDD...
On 18/07/18 01:44, Nicolas Charles wrote:
Hi Neto,
You should list the SSD model also - there are pleinty of
Ok, so dropping the cache is good.
How are you ensuring that you have one test setup on the HDDs and one on
the SSDs? i.e do you have 2 postgres instances? or are you using one
instance with tablespaces to locate the relevant tables? If the 2nd case
then you will get pollution of shared_buffer
On 07/17/2018 04:05 PM, Neto pr wrote:
> 2018-07-17 10:55 GMT-03:00 Fabio Pardi :
>> Also i think it makes not much sense testing on RAID 0. I would start
>> performing tests on a single disk, bypassing RAID (or, as mentioned, at
>> least disabling cache).
>>
>
> But in my case, both the 2 SSD
Le 17/07/2018 à 16:00, Neto pr a écrit :
2018-07-17 10:44 GMT-03:00 Nicolas Charles :
Hi Neto,
You should list the SSD model also - there are pleinty of Samsung EVO drives
- and they are not professional grade.
Among the the possible issues, the most likely (from my point of view) are:
- TRIM
Le 17/07/2018 à 15:50, Robert Zenz a écrit :
On 17.07.2018 15:44, Nicolas Charles wrote:
- Partitions is not correctly aligned on the SSD blocks
Does that really make a noticeable difference? If yes, have you got some further
reading material on that?
I was pretty sure it was, but looking at
2018-07-17 10:55 GMT-03:00 Fabio Pardi :
> If you have a RAID cache, i would disable it, since we are only focusing
> on the disks. Cache can give you inconsistent data (even it looks like
> is not the case here).
>
> Also, we can do a step backward, and exclude postgres from the picture
> for the
2018-07-17 10:44 GMT-03:00 Nicolas Charles :
> Hi Neto,
>
> You should list the SSD model also - there are pleinty of Samsung EVO drives
> - and they are not professional grade.
>
> Among the the possible issues, the most likely (from my point of view) are:
>
> - TRIM command doesn't go through the
If you have a RAID cache, i would disable it, since we are only focusing
on the disks. Cache can give you inconsistent data (even it looks like
is not the case here).
Also, we can do a step backward, and exclude postgres from the picture
for the moment.
try to perform a dd test in reading from di
On 17.07.2018 15:44, Nicolas Charles wrote:
> - Partitions is not correctly aligned on the SSD blocks
Does that really make a noticeable difference? If yes, have you got some further
reading material on that?
Hi Neto,
You should list the SSD model also - there are pleinty of Samsung EVO
drives - and they are not professional grade.
Among the the possible issues, the most likely (from my point of view) are:
- TRIM command doesn't go through the RAID (which is really likely) - so
the SSD controller
On Tue, Jul 17, 2018 at 1:00 AM, Neto pr wrote:
> Dear,
> Some of you can help me understand this.
>
> This query plan is executed in the query below (query 9 of TPC-H
> Benchmark, with scale 40, database with approximately 40 gb).
>
> The experiment consisted of running the query on a HDD (Raid
2018-07-17 10:04 GMT-03:00 Neto pr :
> Sorry.. I replied in the wrong message before ...
> follows my response.
> -
>
> Thanks all, but I still have not figured it out.
> This is really strange because the tests were done on the same machine
> (I use HP ML110 Proliant 8gb RAM - Xeon 2.
Sorry.. I replied in the wrong message before ...
follows my response.
-
Thanks all, but I still have not figured it out.
This is really strange because the tests were done on the same machine
(I use HP ML110 Proliant 8gb RAM - Xeon 2.8 ghz processor (4
cores), and POSTGRESQL 10.1.
-
As already mentioned by Robert, please let us know if you made sure that
nothing was fished from RAM, over the faster test.
In other words, make sure that all caches are dropped between one test
and another.
Also,to better picture the situation, would be good to know:
- which SSD (brand/model) a
> Why did the HDD (7200 rpm) perform better?
Are these different systems? Have you ruled out that during the HDD test the
data was available in memory?
Can you post make and model of the SSD concerned? In general the cheaper
consumer grade ones cannot do sustained read/writes at anything like
their quoted max values.
regards
Mark
On 17/07/18 17:00, Neto pr wrote:
Dear,
Some of you can help me understand this.
This query plan is executed i
Can you show the configuration of postgresql.conf?
Query configuration method:
Select name, setting from pg_settings where name ~ 'buffers|cpu|^enable';
On 2018年07月17日 13:17, Benjamin Scherrey wrote:
What's the on disk cache size for each drive? The better HDD
performance problem won't be susta
What's the on disk cache size for each drive? The better HDD performance
problem won't be sustained with large amounts of data and several different
queries.
- - Ben Scherrey
On Tue, Jul 17, 2018, 12:01 PM Neto pr wrote:
> Dear,
> Some of you can help me understand this.
>
> This query plan i
Dear,
Some of you can help me understand this.
This query plan is executed in the query below (query 9 of TPC-H
Benchmark, with scale 40, database with approximately 40 gb).
The experiment consisted of running the query on a HDD (Raid zero).
Then the same query is executed on an SSD (Raid Zero).
31 matches
Mail list logo
