Высокая нагрузка VPS не всегда означает нехватку процессорных ядер. Начните с коротких измерений: отдельно посмотрите занятость CPU, ожидающие задачи и конкретные процессы. Один снимок top не показывает картину за весь день.

1. Узнайте число процессоров и общую нагрузку

nproc
uptime
top

В top нажмите 1, чтобы показать ядра отдельно, P — сортировать процессы по CPU, q — выйти. Load average в uptime показывает среднее число выполняемых или ожидающих задач за 1, 5 и 15 минут, а не процент загрузки.

Сопоставляйте load с числом доступных CPU, но учитывайте задачи в непрерываемом ожидании, например дискового ввода-вывода. Высокий load при свободном CPU требует проверки диска, файловых систем и зависших операций.

2. Снимите несколько интервалов mpstat

sudo apt update
sudo apt install sysstat
mpstat -P ALL 1 5

Установка пакета добавляет диагностические утилиты. Команда измеряет пять секунд и завершается; это не полноценный мониторинг истории. Строка all — агрегат, остальные относятся к отдельным CPU.

%usr отражает выполнение пользовательского кода, %sys — работу ядра, %idle — простой. %iowait связано с ожиданием I/O, но само по себе не доказывает неисправность диска. %steal на виртуальной машине помогает заметить ожидание процессорного времени у гипервизора.

3. Найдите процесс, создающий нагрузку

pidstat -u 1 5
ps -eo pid,ppid,user,comm,%cpu,%mem --sort=-%cpu | head -n 16

В pidstat сравнивайте интервалы, а в ps помните, что %CPU — оценка за время жизни процесса, не тот же мгновенный показатель. Многопоточное приложение в некоторых режимах отображения может иметь больше 100% за счёт нескольких ядер.

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

4. Сопоставьте с работой приложения

Запишите время проблемного запроса и сравните с журналом приложения. При росте user CPU ищите дорогие вычисления; при росте system CPU — частые системные вызовы, сеть или I/O. Для вывода нужны дополнительные наблюдения, а не универсальный совет увеличить тариф.

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

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

Эти команды не меняют лимиты ресурсов и не останавливают службы. Сначала устраните причину нагрузки; при необходимости отдельно ограничьте фоновую задачу. Не запускайте stress-тест на сервере с рабочими сайтами ради подтверждения уже наблюдаемой проблемы.

Связанные инструкции

Официальные источники