Высокая нагрузка: кто съел процессор и память

Сервер тормозит, сайт отвечает через раз. Прежде чем увеличивать тариф, выясните, во что именно упирается система: в процессор, память или диск. От этого зависит решение.

Load average#

$ uptime$ nproc

uptime показывает три числа — среднюю нагрузку за 1, 5 и 15 минут. Грубо: число процессов, которые работают или ждут процессора либо диска. Сравнивайте его с количеством ядер из nproc: на 2 ядрах load 2 — полная загрузка, 6 — очередь втрое длиннее, чем система успевает обработать.

Кто потребляет ресурсы#

top есть везде. htop и btop нагляднее — ставятся одной командой:

$ apt install -y htop btop$ htop

• В htop F6 выбирает сортировку: по CPU% или MEM%. F9 отправляет сигнал процессу.
• В top: Shift+P — сортировка по процессору, Shift+M — по памяти.
• Строка %Cpu(s) в top: us — программы, sy — ядро, wa — ожидание диска, st — время, которое у виртуальной машины забрал гипервизор.

Память#

$ free -h

Смотрите на столбец available, а не free: Linux занимает свободную память под кэш и отдаёт её программам по требованию. Мало available и активно используемый swap — памяти действительно не хватает.

$ ps aux --sort=-%mem | head -10

OOM killer#

Когда память кончается совсем, ядро завершает самый «тяжёлый» процесс. Со стороны это выглядит как внезапно упавшая база данных или приложение. Проверьте:

$ journalctl -k | grep -i -E 'out of memory|oom-kill'$ dmesg -T | grep -i oom

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

Диск#

$ apt install -y iotop sysstat$ iotop -oPa$ iostat -x 2 5

iotop покажет процессы, которые больше всего читают и пишут. В iostat обращайте внимание на %util и await: постоянные значения %util около 100 означают, что диск не успевает.

Частые причины#

Проверьте результат#

После изменений понаблюдайте за uptime и free -h в часы пик. Чтобы сравнивать с прошлым, включите сбор истории метрик — об этом отдельная статья.