Re: Why HDD performance is better than SSD in this case

>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 500GB"
https://superuser.com/questions/1169810/smart-data-of-a-new-ssd

Regards,
Imre

Neto pr <netopr9(at)gmail(dot)com> ezt írta (időpont: 2018. júl. 18., Sze, 3:17):

> 2018-07-17 22:13 GMT-03:00 Neto pr <netopr9(at)gmail(dot)com>:
> > 2018-07-17 20:04 GMT-03:00 Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz
> >:
> >> 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_buffers if you don't restart between the
> HHD
> >> and SSD tests. If you have 2 instances then you need to carefully check
> the
> >> parameters are set the same (and probably shut the HDD instance down
> when
> >> testing the SSD etc).
> >>
> > Dear Mark
> > To ensure that the test is honest and has the same configuration the
> > O.S. and also DBMS, my O.S. is installed on the SSD and DBMS as well.
> > I have an instance only of DBMS and two database.
> > - a database called tpch40gnorhdd with tablespace on the HDD disk.
> > - a database called tpch40gnorssd with tablespace on the SSD disk.
> > See below:
> >
> > postgres=# \l
> > List of databases
> > Name | Owner | Encoding | Collate | Ctype |
> > Access privileges
> >
> ---------------+----------+----------+-------------+-------------+-----------------------
> > postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
> > template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
> > =c/postgres +
> > | | | | |
> > postgres=CTc/postgres
> > template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
> > =c/postgres +
> > | | | | |
> > postgres=CTc/postgres
> > tpch40gnorhdd | user1 | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
> > tpch40gnorssd | user1 | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
> > (5 rows)
> >
> > postgres=#
> >
> > After 7 query execution in a database tpch40gnorhdd I restart the DBMS
> > (/etc/init.d/pg101norssd restart and drop cache of the O.S.) and go to
> > execution test with the database tpch40gnorssd.
> > You think in this case there is pollution of shared_buffers?
> > Why do you think having O.S. on SSD is bad? Do you could explain better?
> >
> > Best regards
> > []`s Neto
> >
>
> +1 information about EVO SSD Samsung:
>
> Model: 850 Evo 500 GB SATA III 6Gb/s -
> http://www.samsung.com/semiconductor/minisite/ssd/product/consumer/850evo/
>
>
> >> I can see a couple of things in your setup that might pessimize the SDD
> >> case:
> >> - you have OS on the SSD - if you tests make the system swap then this
> will
> >> wreck the SSD result
> >> - you have RAID 0 SSD...some of the cheaper ones slow down when you do
> this.
> >> maybe test with a single SSD
> >>
> >> regards
> >> Mark
> >>
> >> On 18/07/18 01:04, Neto pr wrote (note snippage):
> >>
> >>> (echo 3> / proc / sys / vm / drop_caches;
> >>>
> >>> discs:
> >>> - 2 units of Samsung Evo SSD 500 GB (mounted on ZERO RAID)
> >>> - 2 SATA 7500 Krpm HDD units - 1TB (mounted on ZERO RAID)
> >>>
> >>> - The Operating System and the Postgresql DBMS are installed on the SSD
> >>> disk.
> >>>
> >>>
> >>
>
>