Мониторинг ресурсов VPS: htop, iotop и vnstat

Коротко

Тормоза VPS почти всегда связаны с одним из четырёх ресурсов: процессором, памятью, диском или сетью. Чтобы понять, какой из них упирается, выполните htop для процессов и нагрузки, sudo iotop -o для диска, vnstat -d для трафика и free -h с df -h для памяти и места. По выводу видно, какой процесс ест ресурс и в какой момент.

Инструменты стандартные и ставятся из репозитория Ubuntu. Их не нужно настраивать, достаточно понимать, что показывает каждый.

Зачем мониторить руками

Общие графики полезны, чтобы увидеть тренд, но для поиска причины нужна детализация на самом сервере. Если сайт тормозит, полезно знать, какой процесс съедает память: nginx, PHP-FPM или база. Если диск занят на 100 процентов, нужно понять, кто пишет на диск. Эти вопросы решают командами на самом сервере.

Есть и обратная задача: не ждать, пока всё рухнет. Регулярная проверка раз в неделю и быстрый взгляд после каждого изменения помогают заметить рост нагрузки заранее.

Шаг 1. htop: процессы и загрузка

Установка и запуск:

sudo apt install htop
htop

Вверху экрана полоски нагрузки по каждому ядру, ниже — память и своп. Полоска Mem показывает занятую память, Swap — использование свопа. Если своп заполнен, сервер уже работает медленнее, даже если процессор свободен.

В таблице процессов колонка %CPU показывает нагрузку, %MEM — долю памяти, COMMAND — программу. Сортировку переключайте клавишами F6 или щелчком по заголовку колонки. Клавиша F9 отправляет сигнал процессу, но её надо использовать осторожно: убивать процесс базы без причины не стоит.

Выход — клавиша q. Если htop не установлен, его аналог — команда top, которая есть всегда.

Шаг 2. free и df: память и место

Два коротких вопроса: есть ли память и есть ли место на диске.

free -h
df -h /

free -h показывает колонку available. Это память, которую система может выделить новым процессам, не трогая своп. Если available ниже 300–500 МБ при высокой загрузке, памяти не хватает. df -h / показывает занятость корневого раздела. Заполнение выше 85–90 процентов — повод разобраться, а не ждать ошибки.

Самый быстрый способ найти большие каталоги:

sudo du -sh /var/* | sort -h | tail -n 5

Команда выводит пять самых больших каталогов в /var. Обычно это логи, кэш пакетов или базы данных. Логи можно очистить с помощью journalctl --vacuum-size=200M, но прежде разберитесь, почему они выросли.

Шаг 3. iotop: кто грузит диск

Когда сервер тормозит, но процессор и память в порядке, часто виноват диск. iotop показывает чтение и запись по процессам:

sudo apt install iotop
sudo iotop -o

Флаг -o показывает только процессы, которые реально читают или пишут. Без него в списке будет всё подряд, и найти нужное сложно. Колонки DISK READ и DISK WRITE показывают скорость, а COMMAND — программу. Например, mysqld с постоянной записью значит, что база активно пишет, и стоит проверить её настройки и логи.

Параметр -P показывает только процессы, без отдельных потоков. Параметр -a выводит накопленный объём ввода-вывода с момента запуска, а не скорость. Для записи в файл используйте пакетный режим: sudo iotop -b -o -n 10 > io.log (-b отключает интерактивный экран, -n 10 останавливает программу после десяти обновлений).

Для работы iotop нужны права root, поэтому используем sudo.

Шаг 4. vnstat: трафик

vnstat собирает статистику по сетевому интерфейсу и показывает объём входящего и исходящего трафика. Установка стандартная:

sudo apt install vnstat

Основные команды:

vnstat -d
vnstat -m
vnstat -h
vnstat -l

vnstat -d показывает трафик по дням, vnstat -m — по месяцам, vnstat -h — почасово за последние сутки, а vnstat -l запускает мониторинг в реальном времени, выход по Ctrl+C. Для конкретного интерфейса добавьте -i, например vnstat -i eth0 -d.

Если база пустая сразу после установки, статистика появится через несколько минут. Команда vnstat -l показывает скорость прямо сейчас, что удобно при диагностике. Список интерфейсов, за которыми следит vnstat, выводит vnstat --iflist: в нём нужно выбрать основной, обычно eth0 или ens3.

Если у вашего тарифа есть лимит трафика (например, он есть у линейки 10G VPS в Польше), сравнивайте с ним показания vnstat. Помните, что vnstat считает то, что видит сам сервер, а учёт для лимита ведёт платформа, поэтому цифры могут слегка расходиться. Подробнее о том, как считать объём, — в статье трафик и лимиты VPS.

Графики в кабинете EGN

Часть проверок можно сделать, не заходя на сервер. В карточке VPS есть вкладка «Мониторинг»: графики процессора, оперативной памяти, входящего и исходящего трафика, чтения и записи диска. Замер делается раз в минуту, период переключается кнопками над графиками, а при наведении виден точный момент и значение. Если вкладка помечена «скоро», для вашей услуги графики ещё не включены, и тогда работает всё, что описано выше.

Как пользоваться этим вместе с командами:

• график показывает, когда начались тормоза, а htop и iotop показывают, кто виноват. Откройте график, найдите время всплеска и сопоставьте его с логами;
• по графику записи на диск видно ночные задачи (бэкапы, логротейт), которые днём не заметны;
• вкладка «Логи» в той же карточке выводит консоль загрузки сервера (ядро и systemd): она выручает, когда сервер завис после перезагрузки и SSH недоступен.

Пример: сайт тормозит по вечерам

Классический случай. Сайт открывается медленно примерно с 19 до 22 часов. Порядок проверки:

1. Днём и вечером запустите htop. Если процессор не загружен, а память на пределе, причина в памяти.
2. Посмотрите колонку %MEM и найдите, кто занимает больше всего. Допустим, это php-fpm с десятком процессов по 200 МБ.
3. Проверьте free -h: available ниже 300 МБ, своп заполнен.
4. Уменьшите число процессов PHP-FPM или увеличьте память тарифа, затем повторите измерение в тот же час.

Если процессор и память в порядке, а iotop -o показывает постоянную запись mysqld, причина в базе: например, включён медленный лог или частые записи сессий. Тогда разбирайтесь с настройками базы, а не с сервером.

Пример: что вы видите в iotop и что с этим делать

Допустим, sudo iotop -o показал такой вывод в момент тормозов:

Total DISK READ: 0.00 B/s | Total DISK WRITE: 14.50 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  COMMAND
 2214 be/4 mysql      0.00 B/s    12.80 M/s  mysqld
  871 be/4 root       0.00 B/s     1.10 M/s  rsyslogd

Запись на диск 14,5 МБ/с, из них почти всё делает mysqld. Это не обязательно ошибка: базы пишут постоянно. Но если запись растёт именно в момент тормозов, стоит проверить журнал медленных запросов, включённое логирование каждого запроса и частоту сохранения сессий. Сам rsyslogd тоже пишет, но на два порядка меньше, поэтому логи системы здесь не виноваты.

Такой разбор экономит часы. Вместо того чтобы переустанавливать сервер или менять тариф, вы находите конкретный процесс и конкретный режим его работы. Если выводы стабильно указывают на базу, статья про базы данных MySQL и PostgreSQL на VPS покажет, как её настроить.

Чек-лист раз в неделю

Регулярная проверка занимает пять минут и позволяет заметить рост нагрузки до того, как сайт начнёт тормозить:

free -h
df -h /
sudo ss -tlnp
vnstat -m
uptime

Первая команда показывает память, вторая — диск, третья — слушающие порты: если появился неожиданный порт, выясните, какая программа его открыла. Четвёртая показывает трафик за месяц, пятая — нагрузку. Запишите цифры в заметки, и через несколько недель будет видно, растут ли они.

Что делать при росте нагрузки

Рост нагрузки от недели к неделе — сигнал, а не приговор. Порядок действий:

1. Найдите процесс, который вырос, с помощью htop и iotop.
2. Проверьте, нет ли в его логах ошибок и повторяющихся действий.
3. Оптимизируйте приложение или настройте его лимиты: число воркеров, размер кэша, частоту задач.
4. Если оптимизация не помогает, а ресурсы стабильно на пределе, переходите к выбору конфигурации. Статья как выбрать конфигурацию VPS поможет оценить нужный тариф.

Не меняйте тариф вслепую. Больше памяти не решит утечку в приложении, а больше ядер не ускорит запросы, которые ждут диск.

Таблица: симптом, причина и решение

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

Смотреть один раз и делать выводы. Нагрузка меняется по времени. Проверяйте в пиковые часы и сравнивайте несколько замеров.

Убивать процессы без понимания. F9 в htop отправит сигнал сразу. Если это база, вы рискуете потерять данные. Сначала выясните, что это за процесс.

Путать свободную память и доступную. Колонка free мала почти всегда, это нормально. Смотрите на available.

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

Вопросы и ответы

Нужно ли ставить внешний мониторинг, если есть htop?

Для разовой диагностики htop достаточно. Для постоянного наблюдения удобнее мониторинг с оповещениями: он пришлёт сообщение, когда диск или память достигнут порога.

Почему iotop показывает нули?

Скорее всего, не хватает прав (запускайте с sudo) или в ядре не включён учёт задержек ввода-вывода. Если iotop жалуется на task_delayacct, включите его командой sudo sysctl kernel.task_delayacct=1 (на ядрах 5.14 и новее). После перезагрузки настройка сбросится, пока вы не пропишете её в /etc/sysctl.d/.

Можно ли смотреть всё через одну команду?

Нет, у каждого ресурса свой инструмент. Но для быстрого обзора подойдёт htop и free -h вместе.

Итог

Тормоза VPS раскладываются по четырём ресурсам. htop и free -h показывают процессор и память, iotop -o — диск, vnstat -d и vnstat -l — трафик, df -h / — место. Смотрите на пике нагрузки и сравнивайте замеры, а не делайте выводы по одному. Дальше полезно вернуться к выбору конфигурации VPS: если ресурсов стабильно не хватает, пора менять тариф.

Сервер под VPS за пару минут — egnetwork.ru