☰

Недостатки использования ZFS-записи размером 16 КБ вместо 128 КБ

tag-icon • tag-icon zfs qemu performance-tuning
Недостатки использования ZFS-записи размером 16 КБ вместо 128 КБ

Я использую Proxmox на выделенном сервере. Для производства я все еще использую ext4, но я решил начать возиться с ZFS.

Поэтому я создал два отдельных пула хранения ZFS с разными размерами записей:

  • 128k для всего, кроме MySQL/InnoDB
  • 16k для MySQL/InnoDB (потому что 16k — это размер страницы InnoDB по умолчанию, который я использую)

Я добавил этот пул 16k, чтобы проверить, действительно ли это влияет на производительность базы данных MySQL/InnoDB. Так что это действительно влияет. У меня примерно на 40% больше транзакций в секунду и на 25% меньше задержка (я тщательно протестировал это сsysbenchитпцк).

По практическим соображениям на данный момент я бы предпочел использовать один большой пул с размером записей 16 КБ вместо двух отдельных частей (16 КБ и 128 КБ).Я знаю, что могу создать подтома в одном пуле ZFS и задать им разные размеры записей, но это то, чего я хочу избежать. Я предпочитаю, чтобы это можно было контролировать из Proxmox GUI.

Мои вопросы:

  1. С какими недостатками я могу столкнуться, если начну использовать небольшой (16 КБ) размер записи для всего вместо 128 КБ (он был установлен по умолчанию в Proxmox)?

  2. Есть ли у образа диска QEMU эквивалент innodb_page_size? Если есть - то какой у него размер?

    Я попытался проверить это с помощью qemu-img info:

     $ qemu-img info vm-100-disk-0.raw
 image: vm-100-disk-0.raw
 file format: raw
 virtual size: 4 GiB (4294967296 bytes)
 disk size: 672 MiB

Использование сервера:

  • контейнеры для www/php (тонны мелких файлов, но внутри файла контейнера на диске)
  • контейнеры для приложений java/spring (они создают много логов)
  • контейнеры для баз данных mysql/innodb (объяснения не требуются)
  • локальные операции резервного копирования/восстановления, включая сжатие резервных копий
  • возня с большими gzip-файлами (не каждый день, низкий приоритет)

решение1

Короткий ответ:Это действительно зависит от ожидаемого варианта использования. Как правило, размер записи по умолчанию 128 КБ является хорошим выбором для механических дисков (где задержка доступа определяется временем поиска + задержкой вращения). Для пула из одних SSD я бы, вероятно, использовал 16 КБ или максимум 32 КБ (только если последний вариант обеспечивает значительное повышение эффективности сжатия ваших данных).

Длинный ответ:С пулом HDD я рекомендую придерживаться размера записей по умолчанию 128K для наборов данных и использовать 128K volblocksize для zvol. Обоснование в том, что задержка доступа для HDD 7.2K RPM определяется временем поиска, котороенетмасштабируем с recordsize/volblocksize. Давайте займемся математикой: среднее время поиска жесткого диска 7,2 КБ составляет 8,3 мс, в то время как чтение блока 128 КБ занимает всего ~1 мс. Поэтому команда head seek (с задержкой 8 мс+) для чтения небольших блоков 16 КБ кажется расточительной, особенно учитывая, что для небольших чтений/записей вы все равно страдаете от задержки r/m/w. Более того, небольшой размер записи означает большие накладные расходы на метаданные и худшее сжатие. Таким образом, в то время как InnoDB выдает 16 КБ ввода-вывода, и для выделенного набора данных можно использовать размер записи 16 КБ, чтобы избежать усиления r/m/w и записи, для наборов данных смешанного использования (т. е. тех, которые вы используете не только для самой базы данных, но и для более общих рабочих нагрузок) я бы рекомендовал остановиться на 128 КБ, особенно учитывая влияние сжатия от небольшого размера записи.

Однако для пула SSD я бы использовал гораздо меньший volblocksize/recordsize, возможно, в диапазоне 16-32K. Обоснование в том, что SSD имеют гораздо меньшее время доступа, но ограниченную выносливость, поэтому запись полного блока 128K для небольших записей кажется чрезмерной. Более того, усиление пропускной способности ввода-вывода, вызванное большим размером записей, гораздо более тревожно на устройстве с высоким IOP, чем современные SSD (т. е. вы рискуете перегрузить свою пропускную способностьдо(достижение предела IOP).

решение2

Я рекомендую настроитьесли и когдавы столкнулись с проблемой.

По умолчанию в ZFS размер записи составляет 128 КБ, и это приемлемо и допустимо для большинства конфигураций и приложений.

Исключениями из этого правила являются:

  • определенные приложения баз данных; меньшее значение может быть уместным.
    Компромисс в том, что сжатие будет гораздо менее эффективным, что может иметь большее влияние на производительность, чем большее количество транзакций!!
  • большие рабочие нагрузки мультимедиа (например, редактирование видео); полезно большее значение
  • определенные рабочие нагрузки, выходящие за рамки обычных вариантов использования ZFS

Если вы считаете, что производительность бенчмарка базы данных лучше при определенном размере записи, используйте его!
Но вы тестировали с реалистичнымне-бенчмаркинграбочей нагрузки, чтобы убедиться, что вы настраиваетесь на правильный путь?

решение3

Если это имеет значение, то в документации zfs рекомендуется установить «recordsize=16K».

https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#innodb

EDIT: Я только что вернул эту настройку после того, как изменил ее менее чем на 12 часов на сервере proxmox для виртуального сервера с довольно большой базой данных (>60 ГБ данных). Сервер серьезно отстал в анализе данных. Фактически, 'z_rd_int_' процессы подскочили с низкого уровня использования ЦП до примерно 5% каждый, в то время как 'z_wr_int_' обработано снизилось использование процессора - вероятно, потому, что было обработано меньше данных.

Однако изменение алгоритма хеширования на edonr ( zfs set checksum=edonr vmpool) оказало положительное влияние: perf topбольше не отображается SHA256TransformBlocksкак верхняя функция ядра.

Таким образом, рекомендация не во всех случаях оказывается хорошей — ее можно вернуть к исходному набору.

Связанный контент