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

Question

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

EBS объявляет физический_блок_размер и логический_блок_сайт как 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 всегда выполняет ввод / вывод в блоках 128K?

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

Answer 1

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

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

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

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