VDS · Наблюдение и производительность

Нагрузка на диск: iostat и iotop

Как понять, упирается ли машина в диск, кто именно пишет, и как соотнести цифры с ограничением скорости на вашей ступени VDS.

Обновлено 23 августа 2026 г.

Диск — самая частая причина «всё тормозит, а процессор свободен». Процессы стоят в ожидании ввода-вывода, средняя нагрузка растёт, но htop показывает почти нулевой CPU%. Разберёмся, как это увидеть цифрами.

Сколько вам положено

Диски на узлах NVMe, но скорость ограничена по ступени: запись — 60 МБ/с на ядро, но не ниже 60 и не выше 400 МБ/с, чтение вдвое выше записи. Сверх полки допускается всплеск втрое выше на 30 секунд — этого хватает на распаковку архива или сборку проекта, но не на непрерывную заливку терабайта.

СтупеньЯдерЗапись, МБ/сЧтение, МБ/с
VDS-1160120
VDS-22120240
VDS-34240480
VDS-46360720
VDS-5 и VDS-68 и 10400800

Если ваши измерения упираются ровно в эти числа — вы достигли полки, а не сломались. Дальше помогает только переход на ступень выше.

iostat: общая картина

apt install -y sysstat       # Debian, Ubuntu
dnf install -y sysstat       # AlmaLinux, CentOS Stream

iostat -xz 2

Команда печатает срез каждые две секунды. Первый вывод — среднее с момента загрузки, его пропускайте. Смотрите на строку vda или sda:

  • r/s, w/s — операций чтения и записи в секунду.
  • rkB/s, wkB/s — мегабайты, делите на 1024. Сравните с таблицей выше.
  • await — среднее ожидание операции в миллисекундах. Единицы — нормально, десятки и сотни — очередь.
  • %util — насколько диск занят. Стабильные 90–100 % означают, что вы уткнулись.

Заодно полезен vmstat 2: колонка wa (io wait) в процентах показывает, сколько времени процессор просто ждёт диск.

iotop: кто именно пишет

apt install -y iotop && iotop -oPa

-o показывает только активные процессы, -P — процессы вместо потоков, -a — накопленный объём с момента запуска. Через минуту наблюдения видно реального виновника: обычно это база данных, сборщик логов или бэкап.

Разовая проверка без интерактива:

iotop -boPan 3 | head -20

Что делать с находкой

  • Пишет журнал. Ограничьте размер: journalctl --vacuum-size=200M и SystemMaxUse=200M в /etc/systemd/journald.conf. Подробнее — Журналы systemd.
  • Пишет база. Проверьте, не идёт ли полное сканирование таблиц из-за отсутствующего индекса, и не выставлен ли слишком маленький буфер, из-за которого всё падает на диск.
  • Бэкап или rsync в рабочее время. Ограничьте скорость: rsync --bwlimit=20M, для архивации — ionice -c3 nice -n19 tar ..., чтобы задача уступала дорогу.
  • Своп. Если диск занят подкачкой — проблема не в диске, а в памяти, читайте Память и подкачка.

Частые ошибки

Мерить скорость через dd с conv=fdatasync и делать выводы по одному прогону: первые секунды идут на всплеске и дают завышенный результат. Корректная методика — в статье Замер скорости диска и сети.

Заполненный диск тоже выглядит как «тормозит»: свободного места нет, служба не может записать временный файл и висит. Сначала проверьте df -h, это одна секунда.