SSD/NVMe VDS: почему падают IOPS и как поймать throttling в Linux

Что видно снаружи: типичные симптомы падения дисковой производительности

На SSD/NVMe в VDS проблема «вчера было быстро, сегодня — нет» обычно проявляется не красивой ошибкой, а косвенными признаками. Важно их быстро распознать и зафиксировать момент деградации.

• Время ответа БД растёт, появляются таймауты, блокировки, очередь запросов раздувается «лавиной».
• В мониторинге увеличивается await (задержка) и %util у диска, даже если r/s и w/s не выглядят экстремальными.
• В логах приложений растёт время операций с файлами (сессии, кэш, временные файлы, очереди).
• CPU может быть умеренным, но система «подвисает» на I/O (процессы в D-state).
• После прогрева (бэкап, компакция, импорт данных) скорость падает сильнее — частый намёк на thermal throttling.

Дальше задача админа — отделить «это внутри ВМ» от «это уровень хоста/железа/политик», и собрать доказательства: когда просело, на каком профиле нагрузки, что происходит с очередями и телеметрией NVMe.

Почему на NVMe/SSD на VDS падают IOPS: карта причин

Ключевая ошибка — пытаться объяснить падение IOPS одной причиной. На практике в VDS часто накладываются несколько факторов сразу.

• Термальное ограничение (NVMe throttling): накопитель или контроллер перегревается на хосте и снижает скорость.
• Конкуренция за общий storage: «соседи» по хосту создают очередь в подсистеме хранения, растёт латентность.
• Лимиты по IOPS/MBps: профиль/квоты на уровне гипервизора или хранилища.
• Неудачный профиль I/O: мелкие синхронные записи, частые fsync, активное журналирование, неудачные настройки БД.
• Файловая система и монтирование: барьеры, метаданные, некорректные опции под вашу нагрузку.
• Деградация устройства: ошибки, износ, внутренние коррекции, проблемы с прошивкой (в госте видно не всегда, но бывает).
• Давление памяти: мало RAM — page cache не спасает, начинается постоянный реальный I/O.

На VDS вы часто не увидите «честную» температуру диска хоста. Но косвенные признаки (пилообразная скорость под нагрузкой, падение после прогрева) плюс доступные SMART/NVMe-счётчики внутри гостя обычно дают достаточно данных, чтобы принять решение.

Если вы выбираете конфигурацию под базы/очереди/кэш, закладывайте запас по диску и памяти заранее: пригодится не только для скорости, но и для стабильности задержек. При необходимости посмотреть варианты можно на странице тарифов VDS.

Быстрый чек-лист диагностики: за 10 минут понять, куда копать

Ниже — минимальный набор шагов, который помогает быстро подтвердить «диск стал медленным» и собрать артефакты для дальнейшего анализа.

Шаг 1. Убедитесь, что тормозит именно диск, а не приложение

Посмотрите, есть ли процессы в D-state и на чём они «висят».

ps axo stat,pid,comm,wchan:32 | awk '$1 ~ /D/ {print}'

Если D-state появляется пачками именно во время провала — это почти всегда I/O (или блокировка на уровне драйвера/сетевого блочного устройства).

Шаг 2. Снимите картину по задержкам и очередям через iostat

Метрика await полезна, но сама по себе не магическая: смотрите динамику, очередь и занятость устройства.

iostat -x 1 30

• await, r_await, w_await — задержка (важна динамика и соответствие типу I/O).
• avgqu-sz — средняя длина очереди: растёт очередь — производительности не хватает.
• %util — если близко к 100% и держится, устройство постоянно занято.

Если %util высокий, avgqu-sz растёт, а IOPS не растут — вы упёрлись в лимит, конкуренцию или throttling. По теме метрик и тестов (включая iotop и нюансы планировщиков) полезно держать под рукой разбор: как читать iostat/iotop и правильно тестировать fio.

Шаг 3. Проверьте планировщик и базовую информацию о блочном устройстве

lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINTS
cat /sys/block/nvme0n1/queue/scheduler

На современных ядрах часто используется none или mq-deadline. На виртуализации выбор зависит от того, как провайдер прокидывает блочное устройство. Не меняйте scheduler «на удачу»: сначала зафиксируйте базовые замеры, затем сравните.

Шаг 4. Посмотрите, нет ли явных проблем с файловой системой и ядром

mount | grep -E ' / | /var | /srv | /home '
dmesg -T | tail -n 200

Ошибки I/O, reset, сообщения NVMe — сильный сигнал, что надо идти в SMART/логи событий и собирать артефакты для провайдера.

NVMe температура и throttling: что реально можно увидеть внутри гостя

Запросы «NVMe temperature» и «NVMe throttling» часто приводят к разочарованию: в VDS вы можете видеть виртуальное NVMe-устройство, и показания будут неполными. Но проверять всё равно стоит: иногда пробрасываются реальные сенсоры или часть SMART.

nvme-cli: smart-log и признаки thermal throttling

Снимите базовую телеметрию.

nvme version
nvme list
nvme smart-log /dev/nvme0
nvme id-ctrl /dev/nvme0 | sed -n '1,120p'

Что полезно в nvme smart-log:

• temperature — текущая температура (если доступна);
• warning_temp_time и critical_comp_time — время в предупредительной/критической зоне;
• media_errors, num_err_log_entries — ошибки/записи логов ошибок.

Даже если температура «заморожена» или нулевая, поля времени в warning/critical иногда обновляются — это прямой маркер перегрева на стороне устройства (или хотя бы триггера температурных состояний).

smartctl для NVMe: когда нужно больше деталей

Иногда smartmontools показывает больше, чем nvme-cli (и наоборот) — имеет смысл проверить обоими.

smartctl --version
smartctl -a /dev/nvme0
smartctl -x /dev/nvme0

• Температурные пороги и историю (если проброшено).
• Счётчики ошибок и reset.
• Оценку износа (если доступна в госте).
• Аномалии в логах ошибок.

Почему перегрев выглядит как «пила» скорости

Термальное ограничение редко означает «всегда медленно». Типовая картина: нагрузка стартует — первые секунды/минуты всё быстро, затем контроллер снижает скорость, чтобы остыть, потом частично восстанавливается. На графике IOPS это выглядит как зубцы или ступени.

Если fio на старте даёт X, через минуту — X/3, потом снова «отпускает» и так по кругу, это очень похоже на thermal throttling (особенно на длительных sequential write/compaction/backup).

Правильный fio benchmark на VDS: как тестировать и не наврать себе

fio легко «обмануть»: тест без direct=1 часто упирается в page cache, слишком маленький объём не прогревает устройство и не показывает деградацию, а неверный профиль (iodepth, numjobs) не похож на реальную нагрузку.

Базовые правила перед тестом

• Тестируйте на отдельном файле/разделе, где это безопасно (учитывайте свободное место).
• Для проверки именно диска используйте direct=1.
• Давайте тесту длиться 60–180 секунд, чтобы поймать деградацию.
• Фиксируйте iodepth и numjobs: это часть результата, а не «технические детали».

Тест 4k random read/write (IOPS) + задержки

fio --name=randread4k --filename=/root/fio.test --size=4G --direct=1 --rw=randread --bs=4k --iodepth=32 --numjobs=1 --time_based=1 --runtime=90 --group_reporting=1
fio --name=randwrite4k --filename=/root/fio.test --size=4G --direct=1 --rw=randwrite --bs=4k --iodepth=32 --numjobs=1 --time_based=1 --runtime=90 --group_reporting=1

• Смотрите не только IOPS, но и clat/lat и percentiles.
• Если IOPS «плывут» вниз при стабильном профиле — фиксируйте время и параллельно снимайте iostat -x.

Тест на устойчивую запись (часто проявляет throttling и кэширование)

fio --name=seqwrite1m --filename=/root/fio.test --size=16G --direct=1 --rw=write --bs=1m --iodepth=16 --numjobs=1 --time_based=1 --runtime=180 --group_reporting=1

Если сначала скорость высокая, а потом падает и стабилизируется на заметно меньшем уровне — это может быть и thermal throttling, и исчерпание внутреннего кэша (актуально для части SSD). Для VDS это важно, потому что бэкапы/архивации/ETL как раз «прогревают» диск.

Как связать метрики: iostat, fio и «ощущения» приложения

Чтобы перестать гадать, сведите на один таймлайн три слоя данных:

• Приложение: рост времени запросов/операций, длина очередей, таймауты.
• ОС: iostat -x (await, avgqu-sz, util), D-state, сообщения ядра.
• Устройство: nvme-cli/smartctl (температура, время в warning/critical, ошибки).

Если await растёт синхронно с провалом IOPS в fio, а затем всё восстанавливается после паузы — это похоже на throttling или внешние лимиты. Если await растёт, но fio держится стабильно, а проблемы только у приложения — копайте в профиль записи (fsync/журналы), swap, нехватку RAM и конкуренцию потоков.

Что делать, если подтвердился thermal throttling

На VDS вы ограничены в контроле физического охлаждения, но варианты всё равно есть — от «сделать нагрузку ровнее» до миграции на другой хост/пул.

1) Снизить пики и сделать I/O «ровнее»

• Ограничьте параллелизм тяжёлых задач (бэкапы, компакции, миграции).
• Разнесите задания по времени, избегайте наложения.
• Подберите numjobs/iodepth: меньше пиков — меньше шанс «разогреть» контроллер.

2) Проверьте, не упираетесь ли вы в журналы и fsync

Базы данных часто создают «дорогой» профиль записи. Иногда правильнее добавить RAM (чтобы реже ходить на диск) или перенастроить чекпоинты/журналирование, чем бесконечно искать «ещё более быстрый NVMe». Для PostgreSQL, например, полезно начать с базовой настройки обслуживания: тюнинг autovacuum и индексов.

3) Соберите артефакты для поддержки провайдера

Если вы уверены, что провал именно на уровне диска, подготовьте пакет данных:

• вывод iostat -x 1 60 во время проблемы;
• результаты fio с временем запуска и параметрами;
• nvme smart-log и/или smartctl -x;
• фрагмент dmesg на предмет NVMe ошибок/сбросов.

С таким набором разговор становится предметным: видно, что просело (latency/queue/util), и поддержке проще принять решение о переносе на другой хост/пул или смене профиля диска.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды Финляндия

Смотреть тарифы

Если это не throttling: частые причины падения IOPS на VDS

Конкуренция и «шумные соседи»

Если деградация возникает по расписанию (например, каждую ночь) или волнами, а SMART не даёт признаков перегрева — часто это общий пул хранения. Косвенный признак: одновременно растёт await, CPU и память в порядке, но любые файловые операции становятся «вязкими».

Лимиты профиля и QoS

Если есть лимит IOPS/MBps, картина похожа на «потолок»: IOPS не растут выше определённого значения, а задержка увеличивается, потому что очередь копится.

Неподходящий размер блока и глубина очереди

4k random write с iodepth=1 и тот же профиль с iodepth=64 — это два разных мира. Делайте несколько fio-тестов под разные профили и анализируйте percentiles задержек, а не только среднее.

Swap и давление памяти

Когда RAM не хватает, система активнее делает page-in/page-out, и даже быстрый NVMe превращается в «бутылочное горлышко». В таких случаях падение IOPS — следствие. Если видите это регулярно, имеет смысл пересмотреть конфигурацию: на странице VDS проще подобрать план с запасом по памяти и диску под вашу нагрузку.

Мини-рукбук: команды, которые стоит держать под рукой

Минимальный набор для дежурного, чтобы быстро собрать картину.

# 1) Диск и задержки
iostat -x 1 30

# 2) Кто висит в D-state
ps axo stat,pid,comm,wchan:32 | awk '$1 ~ /D/ {print}'

# 3) NVMe smart
nvme list
nvme smart-log /dev/nvme0

# 4) SMART через smartctl
smartctl -a /dev/nvme0

# 5) Быстрый fio на IOPS (осторожно с местом под файл)
fio --name=randread4k --filename=/root/fio.test --size=2G --direct=1 --rw=randread --bs=4k --iodepth=32 --numjobs=1 --time_based=1 --runtime=60 --group_reporting=1

Итоги: как быстрее всего локализовать проблему

• Подтвердите факт деградации метриками: iostat -x, задержки, очередь, %util.
• Воспроизведите контролируемо через fio и проверьте «пилу»/просадку после прогрева.
• Параллельно снимите доступные признаки температурных событий и ошибок через nvme-cli и smartctl.
• Если похоже на лимиты/конкуренцию/хост — соберите артефакты и идите в поддержку провайдера.
• Если проблема внутренняя — оптимизируйте профиль записи (БД/кэши/RAM/параллелизм), а не «лечите NVMe» вслепую.

Такая последовательность обычно экономит часы: вы перестаёте спорить с ощущениями и начинаете измерять.