Как проверить, почему медленно работает диск на VPS?

Как понять, что тормозит именно диск

Проблемы с диском часто маскируются под обычные «тормоза сервера». На практике это может выглядеть так:

• команды в терминале выполняются с задержкой;

• сайт открывается рывками, хотя CPU не загружен на 100%;

• база данных долго отвечает на простые запросы;

• бэкапы, импорт/экспорт базы или распаковка архивов сильно замедляют весь VPS;

• в мониторинге виден высокий iowait — ожидание операций ввода-вывода.

iowait — это время, когда процессор вроде бы свободен, но ждёт, пока диск закончит чтение или запись. То есть CPU не работает на полную не потому, что задач нет, а потому что система ждёт диск.

Простая мысль: если CPU свободен, RAM ещё есть, а сервер всё равно тормозит — обязательно проверьте диск.

Сначала проверяем свободное место

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

df -h

Пример вывода:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        30G   26G  3.1G  90% /
tmpfs           512M     0  512M   0% /dev/shm

На что смотреть:

• Use% — процент занятого места;

• Avail — сколько реально осталось свободно;

• Mounted on — куда смонтирован раздел.

Если корневой раздел / занят на 90–95% и выше, сервер уже может вести себя нестабильно. Логам, базе данных, временным файлам и пакетному менеджеру нужно свободное место.

Проверяем inode: место есть, а файлы не создаются

Иногда свободное место на диске есть, но система всё равно не может создавать новые файлы. Такое бывает, когда закончились inode.

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

Проверка inode:

df -ih

Если в колонке IUse% близко к 100%, проблема может быть не в размере файлов, а в их количестве.

Частые источники проблем:

• кэш сайтов и приложений;

• временные файлы;

• старые сессии;

• миллионы мелких файлов в каталогах логов или кэша.

Смотрим ожидание диска через vmstat

Команда vmstat помогает быстро понять, есть ли ожидание диска. Запустим статистику каждые 1 секунду, 5 раз:

vmstat 1 5

В выводе нас особенно интересует колонка wa в блоке CPU:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 210000  90000 620000    0    0     2    20  120  240  4  1 94  1  0
 2  1      0 205000  91000 625000    0    0   800  950  300  600  5  2 60 33  0

Что важно:

• wa — сколько времени CPU ждёт диск;

• bi — блоки, прочитанные с диска;

• bo — блоки, записанные на диск;

• b — процессы, заблокированные в ожидании ресурсов, часто диска.

Если wa периодически подскакивает — это нормально во время бэкапа, обновления или импорта базы. Если wa постоянно высокий, а сервер тормозит, диск действительно может быть узким местом.

Устанавливаем iostat для подробного анализа диска

Для более точной диагностики используют iostat. Он входит в пакет sysstat.

sudo apt update
sudo apt install -y sysstat

Проверяем диск расширенной статистикой:

iostat -xz 1 5

Ключи:

• -x — расширенная статистика по устройствам;

• -z — не показывать полностью пустые устройства;

• 1 5 — обновлять каждую секунду, всего 5 раз.

Сначала вывод может выглядеть тяжеловато, но смотреть нужно не на всё подряд.

Какие показатели iostat важны

В выводе iostat -xz чаще всего смотрят на такие показатели:

• %util

  Показывает, насколько загружено устройство. Если значение часто близко к 100%, диск может быть перегружен.

• await

  Среднее время ожидания операции ввода-вывода. Чем выше значение, тем дольше процессы ждут диск.

• r/s и w/s

  Количество операций чтения и записи в секунду.

• rkB/s и wkB/s

  Скорость чтения и записи в килобайтах в секунду.

• aqu-sz

  Средняя длина очереди запросов к диску. Если очередь растёт, диск не успевает обрабатывать операции.

Простая трактовка:

• высокий %util + высокий await — диск не справляется;

• много w/s и wkB/s — кто-то активно пишет на диск;

• много r/s и rkB/s — идёт активное чтение;

• высокий aqu-sz — запросы копятся в очереди.

Важно: на VPS показатели зависят не только от вашего сервера, но и от нагрузки на физический узел провайдера. Иногда диск медленный не из-за вашего процесса, а из-за соседей по хост-машине.

Ищем процессы, которые грузят диск через iotop

iostat показывает, что диск загружен. Но он не всегда отвечает на вопрос: кто именно виноват. Для поиска процессов удобно использовать iotop.

Установка:

sudo apt update
sudo apt install -y iotop

Запуск только с активными процессами:

sudo iotop -oPa

Что значат ключи:

• -o — показывать только процессы с активным вводом-выводом;

• -P — показывать процессы, а не отдельные потоки;

• -a — накопительная статистика с момента запуска iotop.

В выводе смотрим:

• DISK READ — чтение с диска;

• DISK WRITE — запись на диск;

• IO% — насколько процесс ждёт операции ввода-вывода;

• COMMAND — какая команда или процесс создаёт нагрузку.

Часто виновниками бывают:

• бэкапы;

• импорт или экспорт базы;

• тяжёлые SQL-запросы;

• архивация больших каталогов;

• активное логирование;

• сканирование антивирусом или аудиторами безопасности.

Проверяем системные сообщения о диске

Если диск работает странно, полезно посмотреть системные сообщения ядра. Иногда там видны ошибки файловой системы, устройства или проблемы с вводом-выводом.

dmesg | grep -i -E 'error|fail|io|ext4|xfs|nvme|sda|vda' | tail -50

На VPS физические детали диска часто скрыты, поэтому не всегда будут понятные сообщения. Но если есть ошибки уровня I/O error, EXT4-fs error или похожие предупреждения, это уже повод разбираться глубже.

Также можно посмотреть системный журнал:

journalctl -p warning..err --since "1 hour ago" --no-pager

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

Типичные причины медленного диска

• Не хватает свободного места

  Когда раздел почти забит, системе сложнее нормально работать с логами, временными файлами, базами и обновлениями.

• Слишком много мелких файлов

  Кэш, сессии и временные каталоги могут создать миллионы мелких файлов. В итоге заканчиваются inode или операции с каталогами становятся медленнее.

• Бэкап идёт в рабочее время

  Архивация и копирование больших данных активно читают и пишут на диск. Лучше запускать такие задачи ночью или в периоды низкой нагрузки.

• База данных активно пишет на диск

  Интернет-магазин, CRM или сайт с большим количеством запросов может упираться именно в дисковую подсистему.

• Медленный тариф или перегруженный узел провайдера

  На дешёвых VPS диск может быть общим слабым местом. Если внутри всё спокойно, а await и %util всё равно плохие, стоит проверить вопрос с хостером.

Что делать, если диск действительно тормозит

1. Освободить место

   Удалить старые архивы, временные файлы, лишние логи, неиспользуемые бэкапы.

2. Найти тяжёлые каталоги

   sudo du -h --max-depth=1 /var | sort -h

   Так можно быстро понять, что именно растёт: логи, кэш, базы, бэкапы.

3. Перенести бэкапы с основного диска

   Плохая практика — хранить все резервные копии на том же диске, где работает сайт и база.

4. Настроить logrotate

   Если логи растут без контроля, их нужно ротировать и сжимать.

5. Оптимизировать базу данных

   Проверить медленные запросы, индексы, размер таблиц и частоту тяжёлых операций.

6. Обновить тариф или перейти на NVMe

   Если проект вырос, а диск постоянно становится узким местом, иногда проще взять тариф с более быстрым хранилищем.

Частые ошибки при диагностике диска

• Смотрят только на CPU

  CPU может быть свободен, но сервер всё равно тормозит из-за ожидания диска. Проверяйте wa, iostat и iotop.

• Путают свободное место и скорость диска

  Свободное место важно, но оно не показывает производительность. Для скорости и задержек нужен iostat.

• Запускают бэкапы в пик нагрузки

  Бэкап может временно положить слабый VPS, особенно если одновременно работает база и веб-сервер.

• Игнорируют inode

  Если inode закончились, новые файлы создаваться не будут, даже если место по df -h ещё есть.

• Сразу винят хостера

  Иногда проблема действительно на стороне провайдера, но сначала стоит проверить свои процессы, логи, бэкапы и базы.

Итоги

• Проверили свободное место и inode через df -h и df -ih.

• Посмотрели ожидание диска через vmstat и показатель wa.

• Разобрали iostat -xz и важные метрики: %util, await, r/s, w/s.

• Научились искать процессы, которые читают и пишут на диск, через iotop.

• Разобрали типичные причины медленного диска и базовый порядок действий.

Вывод: если VPS тормозит, не стоит сразу смотреть только на процессор и память. Диск может быть тем самым узким местом, которое замедляет весь сервер. Для первичной диагностики достаточно связки df, vmstat, iostat и iotop.