Свойство ZFS ashift для томов AWS EBS

Каков фактический размер физического сектора томов AWS EBS?

EBS объявляет Physical_block_size и logical_block_size как 512 для ОС.

ubuntu@ip-172-31-28-17:~$ cat /sys/block/xvdi/queue/physical_block_size 
512
ubuntu@ip-172-31-28-17:~$ cat /sys/block/xvdi/queue/logical_block_size 
512

Мы находимся в процессе перехода на Postgres с RDS на инстансы EC2 (ZFS на EBS со сжатием). При создании zpool значение ashift не указывается

ubuntu@ip-172-31-28-17:~$ sudo zpool create pgstripe /dev/xvdf1 /dev/xvdg1 /dev/xvdh1 /dev/xvdi1
....
ubuntu@ip-172-31-28-17:~$ sudo zpool get ashift
NAME      PROPERTY  VALUE   SOURCE
pgstripe  ashift    0       default

Говорят, что значение ashift=9 может повлиять на производительность современных устройств хранения данных. Итак, проверив фактическое значение ashift для пула, мы обнаружили, что это действительно ashift=9

ubuntu@ip-172-31-28-17:~$ sudo zdb -U /etc/zfs/zpool.cache 
pgstripe:
    version: 5000
    name: 'pgstripe'
    state: 0
    txg: 21518
    pool_guid: 18259321190878592884
    errata: 0
    hostname: 'ip-172-31-28-17'
    vdev_children: 4
    vdev_tree:
        type: 'root'
        id: 0
        guid: 18259321190878592884
        create_txg: 4
        children[0]:
            type: 'disk'
            id: 0
            guid: 6596053233879303485
            path: '/dev/xvdf1'
            whole_disk: 0
            metaslab_array: 39
            metaslab_shift: 31
            ashift: 9
            asize: 322116780032
            is_log: 0
            create_txg: 4
        children[1]:
            type: 'disk'
            id: 1
            guid: 10755479908569617562
            path: '/dev/xvdg1'
            whole_disk: 0
            metaslab_array: 37
            metaslab_shift: 31
            ashift: 9
            asize: 322116780032
            is_log: 0
            create_txg: 4
        children[2]:
            type: 'disk'
            id: 2
            guid: 7517133622037333375
            path: '/dev/xvdh1'
            whole_disk: 0
            metaslab_array: 36
            metaslab_shift: 31
            ashift: 9
            asize: 322116780032
            is_log: 0
            create_txg: 4
        children[3]:
            type: 'disk'
            id: 3
            guid: 17044638243598443214
            path: '/dev/xvdi1'
            whole_disk: 0
            metaslab_array: 34
            metaslab_shift: 31
            ashift: 9
            asize: 322116780032
            is_log: 0
            create_txg: 4
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data

Итак, переходя к фактическому вопросу

  1. Каков фактический размер блока томов ebs?
  2. Достаточно ли оптимизирован ashift=9 для базовых томов EBS?
  3. Для EBS будет ли ashift=12 более производительным, чем ashift=9 на пулах с recordsize=128K, учитывая, что zfs всегда выполняет ввод-вывод блоками по 128 КБ?

Уже выполнен нагрузочный тест postgres с этим значением по умолчанию ashift, поэтому повторим то же самое с явным ashift=12.


person The Coder    schedule 06.09.2018    source источник


Ответы (2)


Для EBS размер сектора физического диска полностью абстрагирован. Тома EBS представляют собой сетевое хранилище. Это хранилище может состоять из многих тысяч дисковых накопителей. Современные контроллеры SAN могут одновременно поддерживать несколько типов дисков.

В современных жестких дисках заявленные размеры физических секторов составляют 512 байт и 4096 байт. Однако это исключительно схема адресации, поскольку размер дорожки определяет производительность. Размер дорожки на внешних дорожках диска больше, чем размер дорожки на внутренних дорожках. Некоторые дисководы увеличивают BPI для внутренних дорожек, но это может иметь побочный эффект в виде более высокой частоты ошибок.

Если вы думаете, что можете оптимизировать тома EBS на основе некоторого теоретического размера сектора, вы ошибаетесь. Цифры, которые вы видите в данный момент времени, завтра могут быть совершенно другими. Такие факторы, как контроллер, задержка в сети, скорость сети, расстояние до физического диска и т. д., имеют взаимосвязь.

Вы получите лучшие результаты, используя блоки большего размера. Фактический размер физического сектора больше не является релевантным понятием. Кроме того, вы не можете контролировать размер «логического» физического сектора, который AWS сообщает виртуальной машине.

person John Hanley    schedule 06.09.2018

Производительность EBS (и, по сути, производительность большинства твердотельных накопителей) довольно сильно снижается, если вы используете ashift=9. Вы всегда должны использовать ashift=12, если только у вас нет веских причин этого не делать.

EBS дает вам определенные операции ввода-вывода в секунду и определяет IOP как «до 16 КБ».

Вы добьетесь наилучшей производительности в EBS, включив сжатие lz4 и используя как можно больший размер записи, если только у вас нет причин уменьшать его, так как это сделает сжатие более эффективным. Причины уменьшения размера обычно связаны с использованием приложения, которое записывает страницы меньшего размера. Например, вы можете установить размер записи = 16 КБ для MySQL/InnoDB или размер записи = 8 КБ для PostgreSQL.

Но всегда устанавливайте ashift=12, если у вас нет чрезвычайно веской причины не делать этого, и даже в этом случае такие причины обычно включают увеличение ashift, а не его уменьшение.

person Gordan Bobić    schedule 29.04.2020