Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASAБаза данных захлебывается в дисковом I/O wait, хотя на сервере стоят корпоративные NVMe накопители. Виновник - ZFS recordsize.
Когда под нагрузкой со случайными чтениями в СУБД (например, PostgreSQL с его 8-килобайтными страницами или MySQL с InnoDB в 16 КБ) начинают утилизировать ZFS, инженеры часто сталкиваются с жестким пробивом производительности. Память уходит в космос, задержки растут, а NVMe простаты не видят. Давайте разберем механику этой инженерной боли на уровне ядра.
В классическом мире Linux pagecache оперирует стандартными страницами памяти по 4 КБ. Файловые системы общего назначения вроде ext4 или XFS читают и кэшируют ровно столько, сколько просит приложение.
У ZFS принципиально иная философия. Ее адаптивный кэш ARC хранит блоки данных в оперативной памяти ровно в том же размере, в каком они записаны в пуле - это параметр recordsize. По умолчанию ZFS создает пулы с размером блока в 128 КБ.
Теперь представьте классическую OLTP-нагрузку: случайные чтения по 8 КБ.
Поступающий запрос требует прочитать одну крошечную страницу. Но так как ZFS оперирует блоками по 128 КБ, ARC и L2ARC вынуждены вытащить с NVMe накопителя весь огромный 128-килобайтный блок целиком. Происходит колоссальное избыточное чтение - amplification factor возрастает в 16 раз.
Система забивает шину PCI-e и пропускную способность NVMe мусорными данными, которые СУБД даже не запрашивала. Linux pagecache при этом работает точечно, подтягивая ровно те 8 КБ, которые нужны движку базы данных, не тратя впустую ценные циклы процессора и полосу пропускания памяти.
Пытаясь спасти ситуацию, администраторы увеличивают размер RAM под ARC, но получают обратный эффект. ARC забивается огромными 128-килобайтами блоками, вытесняя действительно горячие метаданные и индексы.
Решение проблемы требует жесткого тюнинга под конкретный движок СУБД. Для баз данных с фиксированным размером страниц параметр recordsize на датасете должен строго соответствовать размеру страницы базы данных:
- zfs set recordsize=8k tank/postgres
- zfs set recordsize=16k tank/mysql
Дополнительно на уровне ядра Linux стоит проверить параметры планировщика ввода-вывода для NVMe дисков. Для многопоточных высоконагруженных систем с прямым доступом к диску через O_DIRECT эффективнее использовать none вместо mq-deadline, исключая лишние накладные расходы на сортировку очередей:
- echo none > /sys/block/nvme0n1/queue/scheduler
Цена ошибки в проектировании дисковой подсистемы - это не просто просадка метрик в Grafana. Это деградация TCO кластера: вы платите за дорогие NVMe накопители Enterprise-класса с высоким ресурсом записи (DWPD), а они деградируют от паразитной нагрузки из-за несоответствия блоков файловой системы и СУБД.
- Инфраструктурный аудит и калькулятор TCO кластера: @Personnel_run_bot (/tma)
- База знаний и разборы: ftops.space
- ftops.space | Run-As-Daemon Infrastructure