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

Дата публикации: 25-09-2026 16:24:20

База данных захлебывается в дисковом I/O wait, хотя на сервере стоят корпоративные NVMe накопители с линейным чтением под 7 GB/s. Метрики диска упираются в потолок по IOPS, утилизация CPU высокая, а p99 латентность запросов улетает в космос. Причина кроется в классическом конфликте архитектур: ZFS ARC cache и стандартный Linux pagecache работают по принципам, которые уничтожают производительность СУБД при случайных чтениях, если не настроен базовый параметр - zfs_fs_recordsize.
Проблема начинается с того, как устроены уровни кэширования. Linux pagecache оперирует страницами памяти по 4 КБ. Стандартные СУБД вроде PostgreSQL или MySQL используют блоки данных по 8 КБ или 16 КБ. Если поверх ext4 или xfs развернуть СУБД, то страница файловой системы и страница базы данных ложатся в память предсказуемо.
ZFS устроена иначе. По умолчанию размер блока (recordsize) в пуле ZFS составляет 128 КБ. Когда база данных делает случайный запрос на чтение одной строки размером 8 КБ, ZFS вынуждена поднимать с NVMe весь блок в 128 КБ, забивая ARC-память и пропускную способность шины мусором. На каждый мелкий запрос мы читаем в 16 раз больше данных, чем нужно. Это явление называют amplification factor, и оно гарантированно приводит к насыщению очереди NVMe-накопителя (nqn / io depth) и росту I/O wait.
ARC (Adaptive Replacement Cache) пытается балансировать между MRU и MFU списками, но при рандомном OLTP-нагрузочном профиле этот механизм не спасает от memory pressure. В отличие от pagecache, который сбрасывает страницы по LRU, ARC держит в памяти огромные 128-килобайтные блоки, вытесняя действительно горячие индексы. В результате мы получаем двойное чтение: сначала промахиваемся мимо раздутого ARC, а затем тратим ресурс NVMe на чтение огромных кусков диска ради пары килобайт полезной полезной нагрузки.
Решение требует жесткой тюнинговки под конкретный workload СУБД. Для баз данных с размером страницы 8 КБ (PostgreSQL) или 16 КБ необходимо создавать файловую систему ZFS с идентичным размером recordsize:
```bash
zfs set recordsize=8k tank/postgres/data
```
Для MySQL/InnoDB оптимальным значением будет 16k:
```bash
zfs set recordsize=16k tank/mysql/data
```
Уменьшение recordsize до размера страницы СУБД убирает коэффициент усиления чтения. Накопители NVMe начинают отдавать честные IOPS вместо обработки избыточного трафика, очередь запросов пустеет, а I/O wait падает до минимальных значений.
Плата за такой тюнинг - рост метаданных и фрагментации пула, но для высоконагруженных баз данных это единственный способ заставить ZFS работать эффективно без деградации SSD и утилизации всей пропускной способности памяти под ненужные блоки.
- Инфраструктурный аудит и калькулятор TCO кластера: @Personnel_run_bot (/tma)
- База знаний и разборы: ftops.space
- ftops.space | Run-As-Daemon Infrastructure

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

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Каждые 5 минут транзакции в PostgreSQL замирают на 3 - ...	0	11.32	24-09-2026
2	Каждые 5 минут транзакции в высоконагруженной PostgreSQL базе внезапно замирают ...	0	11.86	24-09-2026
3	Каждые 5 минут транзакции в PostgreSQL замирают на 3 - ...	0	10.65	25-09-2026
4	Каждые 5 минут транзакции в PostgreSQL замирают на 3 - ...	0	12.14	19-09-2026
5	Каждые 5 минут транзакции в PostgreSQL замирают на 3 - ...	0	9.34	22-09-2026
6	Рег.облако представил сетевые диски на фоне удорожания SSD-накопителей	0	7	27-01-2026
7	Кэш результатов запросов в Postgres Pro: как ускорить часто выполняющиеся запросы и разгрузить базу	0	7.15	15-05-2026
8	Очередь задач на Postgres: SKIP LOCKED + lease/heartbeat + backpressure (практический опыт)	0	12.42	13-01-2026
9	⚠ ЦОДы скоро уйдут под землю В мире формируется новый ...	0	8.12	24-09-2026

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