Re: full_page_writes on SSD?

Поиск
Список
Период
Сортировка
От FarjadFarid\(ChkNet\)
Тема Re: full_page_writes on SSD?
Дата
Msg-id 005701d1277f$2368b6d0$6a3a2470$@checknetworks.com
обсуждение исходный текст
Ответ на Re: full_page_writes on SSD?  (NTPT <NTPT@seznam.cz>)
Список pgsql-general

I am constantly using SSD both on my OS and database and have none of these problems.

 

However I don’t use SSD for O/S’s virtual memory.

 

From what I have read of this thread.

 

Potentially there could also be a situation that SSD is hitting its limit of auto recovery and has been over used.

It is well known that using SSD’s for OS’s virtual memory causes SSDs to wear out much quicker.

 

To really test all these. One needs to use a brand new SSD. Also ensure you are not using O/S’s virtual memory on the same SSD as DB and its log file.

 

You might want to also double check the language of the OS and postgresql installed. As these determine the final size of memory used to read and write.

 

 

 

 

From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of NTPT
Sent: 25 November 2015 12:10
To: Marcin Mańk
Cc: PostgreSQL
Subject: Re: [GENERAL] full_page_writes on SSD?

 

Hi,


I investigate bit about SSD  and how it works and need to be aligned .

And I  conclude that in the ideal world we need a  general --ebs=xxx switch in various linux tools to ensure alignment. Or make calculation by had..

On the market there are SSD disks with page size 4 or 8 kb. But there is  for ssd disk typical property - the EBS - Erase Block Size. If disk operate and write to single sector, whole Erase block must be read by driver electronic, modified and write back to the drive.

On the market there are devices with multiple EBS sizes . 128, 256, 512 1024 1534 2048 kib etc
In my case Samsung 850evo  there are 8k pages and 1536 Erase Block

So first problem with alegment - partition should start on the  Erase block bounduary .  So --ebs  switch in partition tools for propper aignment  would be practical. Or calculate by hand. In my sase 1536 = 3072 512b sectors.

Things get complicate if You use  mdadm raid. Because Raid superblock is located on the begining of the raid  device and  does not fill whole rerase block, it is practical to set in creation of raid  --offset to real filesystem start at next erase block from the begining of raid device so underlying filesystem would be aligned as well.  so --ebs=xxx on mdadm would be practice

And now ext4  so blocksize 4096 . because page size of ssd is 8kb , setting stride´wit is a smallest unit on with filesystem operate in one disk to 2  to fill ssd pagesize is practical. And stripe size set  as ebs/pagesize or as whole ebs . and may be it would be useful to use ext4 --offset to edb as well.

this should align partition, raid and filesystem. fix me if I am wrong.

And  now it is turn for database storage engine. I think try to write on erase block size bounduary and  erase block size amount of data may have some benefits not with the speed but in lower wear-out of the entire ssd disk..

 

 

---------- Původní zpráva ----------
Od: Marcin Mańk <marcin.mank@gmail.com>
Komu: PostgreSQL <pgsql-general@postgresql.org>
Datum: 24. 11. 2015 20:07:30
Předmět: [GENERAL] full_page_writes on SSD?

 

I saw this: http://blog.pgaddict.com/posts/postgresql-on-ssd-4kb-or-8kB-pages

 

It made me wonder: if SSDs have 4kB/8kB sectors, and we'd make the Postgres page size equal to the SSD page size, do we still need full_page_writes?

 

Regards

Marcin Mańk

=

В списке pgsql-general по дате отправления:

Предыдущее
От: Jong-won Choi
Дата:
Сообщение: Unexpected behaviour of 'DEFERRABLE INITIALLY DEFERRED'
Следующее
От: NTPT
Дата:
Сообщение: Re: [GENERAL] Query failed: ERROR: character with byte sequence 0xc2 0x96 in encoding "UTF8" has no equivalent in encoding "WIN1250"