Re: SSD filesystem aligned to DBMS

From: Neto pr <netoprbr9(at)gmail(dot)com>
To: Michael Loftis <mloftis(at)wgops(dot)com>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: SSD filesystem aligned to DBMS
Date: 2018-01-16 18:28:15
Message-ID: CA+TZvYKwXUhbcAY8owrQn1Z0RgPzb1ejhe5z9wYbhGEb_9A1iw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2018-01-16 8:50 GMT-08:00 Michael Loftis <mloftis(at)wgops(dot)com>:

>
> On Tue, Jan 16, 2018 at 08:02 Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
> wrote:
>
>> On Tue, Jan 16, 2018 at 7:47 AM, Neto pr <netoprbr9(at)gmail(dot)com> wrote:
>> > Hi all
>> >
>> > Sorry, but I'm not sure that this doubt is appropriate for this list,
>> but I
>> > do need to prepare the file system of an SSD disk in a way that pointed
>> me
>> > to, which would be a way optimized SSD
>> > to work. I have a disk: SSD: Samsung 500 GB SATA III 6Gb/s - Model:
>> 850 Evo
>> > http://www.samsung.com/semiconductor/minisite/ssd/
>> product/consumer/850evo/
>> >
>> > One person on the list me said that should be partition aligned to 3072
>> not
>> > default 2048, to start on erase block bounduary. And fs block should be
>> 8kb.
>> >
>> > Can you give me a hint of what program I could do this. I have already
>> used
>> > fdisk but I do not know how to do this in Fdisk. I used Linux Debian
>> > 8(Jessie) 64b with Ext4 File system.
>>
>> fdisk is pretty old and can't handle larger disks. You can get a fair
>> bit of control over the process with parted, but it takes some getting
>> used to. As far as I know, linux's ext4 has a maximum block size of
>> 4k. I can't imagine alignment matters to SSDs and I would take any
>> advice as such with a large grain of salt and then if I had questions
>> about performance I'd test it to see. I'm willing to bet a couple
>> bucks it makes ZERO difference.
>
>
> Alignment definitely makes a difference for writes. It can also make a
> difference for random reads as well since the underlying read may not line
> up to the hardware add in a read ahead (at drive or OS Level) and you’re
> reading far more data in the drive than the OS asks for.
>
> Stupidly a lot of this isn’t published by a lot of SSD manufacturers, but
> through benchmarks it shows up.
>
> Another potential difference here with SAS vs SATA is the maximum queue
> depth supported by the protocol and drive.
>
> SSD drives also do internal housekeeping tasks for wear leveling on
> writing.
>
> I’ve seen SSD drives benchmark with 80-90MB sequential read or write,
> change the alignment, and you’ll get 400+ on the same drive with sequential
> reads (changing nothing else)
>
> A specific example https://www.servethehome.com/ssd-
> alignment-quickly-benchmark-ssd/
>
>

Hi all
Searching I checked that In past, proper alignment required manual
calculation and intervention when partitioning. Many of the common
partition tools now handle partition alignment automatically.
For sample, on an already partitioned disk, you can use *parted* (
https://wiki.archlinux.org/index.php/GNU_Parted#Check_alignment )
to verify the alignment of a partition on a device in LInux S.O. This
example I ran i my Samsung SSD 500GB 850 Evo, see below:

-------BEGIN PARTED TOOL
---------------------------------------------------------------------------------
root(at)hp2ml110deb:parted /dev/sdb
(parted) print list
Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
1 0.00B 500GB 500GB ext4

Model: ATA MB1000GCWCV (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 538MB 537MB fat32 boot, esp
2 538MB 992GB 991GB ext4
3 992GB 1000GB 8319MB linux-swap(v1)

(parted) select /dev/sdb
Using /dev/sdb
(parted) align-check
alignment type(min/opt) [optimal]/minimal? opt
Partition number? 1
1 aligned
(parted)
---------------------------- END
--------------------------------------------------

Regards
Neto

>
>>
>> >
>> > If you prefer, just reply to me, since the subject would not be about
>> > postgresql itself. netoprbr9(at)gmail(dot)com
>>
>> No this affects everybody who uses SSDs so let's keep it on list if we
>> can.
>>
>> --
>
> "Genius might be described as a supreme capacity for getting its possessors
> into trouble of all kinds."
> -- Samuel Butler
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message hmidi slim 2018-01-16 18:35:03 Re: OPtimize the performance of a query
Previous Message Pavel Stehule 2018-01-16 18:08:22 Re: OPtimize the performance of a query