База данных захлебывается в дисковом I/O wait, хотя на сервере ...

Дата публикации: 26-09-2026 19:57:23

База данных захлебывается в дисковом 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

Схожие новости

#	Наименование новости	Тональность	Информативность	Дата публикации
1	База данных захлебывается в дисковом I/O wait, хотя на сервере ...	0	8.41	26-09-2026
2	PHP: четыре Active Record в одной клетке — кто быстрее достаёт ваши данные	0	11.1	26-09-2026
3	Доверить сервер ИИ-агенту и не пожалеть: как спать спокойно без SSH	0	12.58	26-09-2026
4	Энтузиаст создал открытую реализацию DLSS 5 Разработчик maanHimself представил OpenDLSS-NR. ...	0	14.84	26-09-2026
5	Фотонная мемристорная квантовая капсула гибернации** — это герметичная камера для ...	0	8.24	26-09-2026
6	Нагрузочное тестирование SAP BW в современных условиях: опыт и практики реального проекта	0	6.98	26-09-2026
7	xk6-sip: мониторинг нагрузочного тестирования VoIP/SIP-звонков	0	17.21	26-09-2026
8	# Концепт: фотонная мемристорная квантовая капсула гибернации, созданная методами 3D-печати ...	0	5.94	26-09-2026
9	Ну что, народ, эпохальный апгрейд официально завершен! Наконец-то полностью перетряхнул ...	0	11.9	26-09-2026

Классификация: Мнения. Схожих патентов: 0. Схожих новостей: 9. Тональность: 0. Информативность: 8.6. Источник: vk.com.