Как посмотреть нагрузку на машину через консоль

Что проверяют

Умеете ли вы быстро понять на сервере, во что упёрлась система: процессор, память, диск или сеть. Python-разработчику часто добавляют вопрос, почему процесс с потоками грузит только одно ядро.

Как отвечать

Идите от общей картины к конкретному процессу:

• uptime или cat /proc/loadavg: load average за 1, 5 и 15 минут. Сравнивать его надо с числом ядер из nproc: 4 на четырёхъядерной машине это полная загрузка, на шестнадцатиядерной пустяк;
• top и htop: процессы по CPU и памяти, строка %Cpu(s) с разбивкой us, sy, wa, st. Высокий wa означает ожидание диска, высокий st говорит, что гипервизор отдаёт ваше процессорное время соседям;
• vmstat 1: очередь процессов r, своп si и so, ожидание ввода-вывода, обновление раз в секунду;
• free -h: смотреть на колонку available, а не free, память под buff/cache ядро отдаст по требованию;
• iostat -x 1 из пакета sysstat: загрузка дисков, %util и задержки await;
• pidstat и ss -s: нагрузка по процессам во времени и сводка по сокетам.

Для Python добавьте инструменты уровня процесса. py-spy top --pid 1234 показывает, в каких функциях сидит работающий интерпретатор, без перезапуска и правки кода. В самом коде ту же картину даёт psutil, а os.getloadavg() возвращает load average.

Про GIL: CPU-bound код в потоках обычного CPython упирается в одно ядро, и top покажет около 100% на процесс при простаивающих остальных ядрах. Выход: multiprocessing, ProcessPoolExecutor или сборка без GIL, которая с Python 3.13 доступна как отдельный вариант интерпретатора.

Где спотыкаются

Читают load average как проценты. Это средняя длина очереди, и на Linux в неё входят процессы, ждущие диска в состоянии D, поэтому высокая нагрузка бывает при почти свободном процессоре.

Паникуют, увидев мало свободной памяти. Кэш страниц это нормально, тревожный признак это активный своп в vmstat.

Смотрят top внутри контейнера и видят ресурсы всего хоста. Реальные лимиты задаёт cgroup, их показывают docker stats или kubectl top pod.