Интерактивный мониторинг: top и htop

Рейтинг: 55.2% · 12 голосов
Подробный курс по диагностике и производительности Linux для админов и DevOps: с чего начать, методология USE, логи (journalctl, dmesg), процессы, CPU, память и OOM, диск и IO (iostat), сеть (ss, tcpdump), системные вызовы и strace, ltrace, perf, флеймграфы, ftrace, eBPF и bpftrace, lsof, мониторинг. Разбор каждого инструмента с чтением вывода.
Ответить
Аватара пользователя
Dmitry_SRE
Сообщения: 47
Зарегистрирован: 11 май 2026, 05:31

Интерактивный мониторинг: top и htop

Сообщение Dmitry_SRE »

Оглавление курса (47)
  1. С чего начать диагностику Linux: методология вместо паники
  2. Первые 60 секунд: экспресс-диагностика нагруженного сервера
  3. Методологии диагностики: USE, RED и здравый смысл
  4. Логи systemd через journalctl: где искать причину
  5. Где лежат логи Linux: /var/log, dmesg и rsyslog
  6. Источники правды: load average, /proc и /sys
  7. Процессы Linux: ps, pstree и состояния процессов
  8. Интерактивный мониторинг: top и htop (вы здесь)
  9. Метрики процессов во времени: pidstat
  10. Приоритеты и ограничения: nice, ionice, cgroups
  11. Сигналы и зависшие процессы: kill, и что делать с D-state
  12. Загрузка CPU: user, system, iowait, steal и контекст-свитчи
  13. Диагностика CPU по ядрам: vmstat и mpstat
  14. Профилирование CPU: perf top и поиск пожирателя
  15. Частоты, троттлинг и NUMA: turbostat и numastat
  16. Память Linux: RSS, VSZ, page cache и миф о нехватке памяти
  17. Сколько памяти занято: free, /proc/meminfo и vmstat
  18. Поиск утечек и пожирателей памяти: smem, pmap, smaps
  19. Swap и подкачка: swapon, swappiness, когда своп - это боль
  20. OOM killer: кто и за что убил процесс
  21. Память ядра и slab: slabtop и куда уходит RAM
  22. Подсистема ввода-вывода: путь запроса от приложения до диска
  23. Диагностика диска: iostat и чтение await, %util
  24. Кто грузит диск: iotop и атрибуция io процессам
  25. Файловые системы: df, du, иноды и куда делось место
  26. Глубокая диагностика блочного слоя: blktrace и biolatency
  27. Кеш страниц и грязные данные: dirty pages, fsync, drop_caches
  28. Сетевой стек Linux: путь пакета и где возникают задержки
  29. Сокеты и соединения: ss и netstat
  30. Захват трафика: tcpdump для диагностики сети
  31. Задержки и потери в сети: ping, mtr, диагностика латентности
  32. Сеть как источник проблем: nftables, conntrack, дропы
  33. Что такое системный вызов и зачем его трассировать
  34. strace: трассировка системных вызовов на практике
  35. strace в бою: почему программа висит, падает или тормозит
  36. ltrace: трассировка вызовов библиотек
  37. Накладные расходы трассировки и безопасные альтернативы
  38. perf: универсальный профайлер Linux
  39. Флеймграфы: визуализация профиля производительности
  40. Трассировка ядра: ftrace и trace-cmd
  41. eBPF: революция в наблюдаемости Linux
  42. Инструменты eBPF на практике: BCC и bpftrace
  43. lsof: открытые файлы, дескрипторы, кто держит файл и порт
  44. Разбор кейса: приложение тормозит - пошаговая диагностика
  45. Непрерывный мониторинг: sar, node_exporter, Grafana, Zabbix
  46. Диагностика в контейнерах: cgroups, лимиты, Docker и Kubernetes
  47. Карта инструментов и сквозной разбор инцидента производительности
Сервер тормозит, сайт отвечает через раз, а ты сидишь по ssh и не понимаешь - кто виноват. Процессор? Память? Диск? Или вообще сосед по гипервизору отъедает такты? Самый быстрый способ это увидеть - открыть интерактивный монитор. Не лезть сразу в логи и не запускать тяжёлый профайлинг, а посмотреть на систему вживую, в реальном времени. Для этого есть два главных инструмента, и спрос на них в поиске огромный: команда top в Linux есть на любой машине из коробки, а htop ставят дополнительно за удобство и цвет.

В этом уроке разберём оба подробно: что означает каждая цифра в шапке, как сортировать и фильтровать, как убить зависший процесс прямо из монитора. Покажем, что в 2026 году правильнее смотреть не только на load average, но и на PSI (pressure stall information). И главное - как читать вывод так, чтобы он что-то тебе говорил, а не просто мигал зелёными столбиками.

top linux: что показывает шапка

Запусти просто без аргументов. Сверху - пять строк заголовка, ниже - таблица процессов. Шапка важнее таблицы, новички про неё забывают и зря. Современная версия (procps-ng, она же стоит в Debian/Ubuntu, Astra Linux, RED OS) выглядит так:

Код: Выделить всё

top - 14:32:08 up 12 days,  3:41,  2 users,  load average: 0.84, 1.12, 1.30
Tasks: 214 total,   1 running, 212 sleeping,   0 stopped,   1 zombie
%Cpu(s):  6.3 us,  2.1 sy,  0.0 ni, 88.0 id,  3.4 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem :   7861.4 total,    402.1 free,   3120.8 used,   4338.5 buff/cache
MiB Swap:   2048.0 total,   1900.0 free,    148.0 used.   4210.2 avail Mem
Разберём построчно.

load average: 0.84, 1.12, 1.30 - средняя нагрузка за 1, 5 и 15 минут. Это не проценты. В Linux в очередь попадают не только процессы, готовые на CPU, но и те, что застряли в непрерывном ожидании диска (состояние D). Поэтому load average в Linux - это смесь нагрузки на процессор и на диск, и сам по себе он не говорит, что именно перегружено. Ориентир - сравнивай с числом ядер (). Если ядер 4, а load 1.30 - система свободна. Если load 8 на тех же 4 ядрах - очередь, всё стоит в пробке. Три числа показывают тренд: если первое больше третьего - нагрузка растёт прямо сейчас; если меньше - пик уже прошёл.

Tasks - сколько процессов всего и в каких состояниях. Смотри на running (реально работают или готовы работать) и на zombie. Один-два зомби - не страшно: это процесс, который завершился, но родитель не прочитал его код возврата, не "похоронил". Сотня растущих зомби - баг в приложении (родитель не делает wait), копай туда; памяти и CPU они не едят, но забивают таблицу процессов.

Строка %Cpu(s) - сердце диагностики. Это проценты, в сумме примерно 100 (это доля за интервал обновления по всем ядрам сразу). Точные значения полей в procps-ng:
  • us (user) - пользовательский режим, обычные процессы. Высокий us = считают код приложения. Нормально для нагруженного сервиса.
  • sy (system) - время в ядре: системные вызовы, работа с сетью и диском через ядро, переключения контекста. Если sy сильно выше us - подозрительно много обращений к ядру (шторм syscalls, частые context switch, лишние fork).
  • ni (nice) - пользовательские процессы с пониженным приоритетом (положительный nice). Обычно около нуля.
  • id (idle) - простой. Чем больше id, тем свободнее процессор. 88 id - дышим спокойно.
  • wa (io-wait) - процессор простаивает, потому что нечего считать: задачи ждут диск или сеть. Об этом ниже отдельно, это важнейший сигнал.
  • hi / si - обслуживание аппаратных (hardware) и программных (soft) прерываний. Обычно близко к нулю. Высокий si бывает при шквале сетевых пакетов (одно ядро разгребает softirq сети).
  • st (steal) - такты, которые у твоей виртуалки украл гипервизор. Тоже разберём отдельно.
Две строки про память - Mem и Swap. Тут классическая ловушка новичка. Видишь free всего 402 MiB и паникуешь? Не спеши. Смотри на buff/cache - 4338 MiB ушли в страничный кэш файловой системы. Это не потеря: ядро отдаст эту память приложению моментально, как только понадобится. Реальный показатель свободного - avail Mem (available) в конце строки Swap: это оценка ядра, сколько можно занять без ухода в своп. Вот если avail Mem близок к нулю И своп активно используется (used в строке Swap растёт, в логах мелькает oom-killer) - тогда памяти действительно не хватает. Маленький used в свопе при большом avail Mem - не повод для паники: ядро могло давно выгрузить туда холодные страницы и забыть про них.

Изображение

top linux: команды управления и чтение таблицы

Команда top в Linux - это интерактивный режим. Жмёшь клавиши, и вид меняется. Самое нужное:
  • P (заглавная) - сортировать по %CPU. Сверху самые прожорливые по процессору. Это поведение по умолчанию.
  • M - сортировать по памяти (%MEM). Ищем утечку? Жмём M.
  • H - показать потоки (threads), а не только процессы. Полезно, когда одно приложение многопоточное и непонятно, какой поток грузит ядро.
  • 1 (единица) - раскрыть строку %Cpu по ядрам. Вместо одной усреднённой строки увидишь cpu0, cpu1 и так далее. Сразу видно, упёрлись ли в одно ядро (однопоточная программа выжимает 100% на cpu3, а остальные спят).
  • c - показать полную командную строку процесса вместо короткого имени.
  • V - дерево процессов (forest view) прямо в top, видно родителей и детей.
  • k - kill, послать сигнал процессу. top спросит PID, потом номер сигнала (по умолчанию 15 - TERM, мягкое завершение; 9 - KILL, жёстко).
  • d или s - сменить интервал обновления (по умолчанию около 3 секунд).
  • q - выйти.
Теперь сама таблица. Колонки, которые читаешь чаще всего:

Код: Выделить всё

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1842 www-data  20   0  712.3m  98.4m  21.2m R 142.3   1.2   3:12.45 php-fpm
  933 mysql     20   0    2.1g   1.1g  18.0m S   8.1  14.3  51:09.10 mysqld
  • PID - номер процесса, его и подставляешь в kill.
  • RES (resident) - сколько реальной оперативки занято физически. Вот это смотри на утечки, а не VIRT. (Оговорка: RES включает разделяемые библиотеки, поэтому сумма RES по всем процессам бывает больше, чем реально занято; для честной картины одного процесса есть колонка RSan / поле PSS в /proc.)
  • VIRT - виртуальное адресное пространство. Обычно сильно завышено и пугает зря: туда входят отображённые файлы, зарезервированные, но не тронутые страницы. RES честнее.
  • S - состояние. R - работает или готов работать, S - спит (нормально, ждёт события), D - непрерывный сон (ждёт диск/IO, плохой знак если таких много и при этом высокий wa), Z - зомби, T - остановлен.
  • %CPU - может быть больше 100, если процесс многопоточный и занял несколько ядер. 142% значит почти полтора ядра.
  • TIME+ - сколько процессорного времени процесс съел за всё время жизни (не реальное время, а именно CPU-time).
htop linux: установить и пользоваться

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

Код: Выделить всё

# Debian / Ubuntu / Astra Linux
sudo apt update && sudo apt install htop

# RHEL / Fedora / RED OS / AlmaLinux
sudo dnf install htop
Запускаешь просто - без sudo. Root нужен только чтобы слать сигналы чужим процессам или менять их приоритет. Актуальная ветка на 2026 - htop 3.x (форк htop-dev, оригинальный автор давно передал проект). Сверху - цветные шкалы по каждому ядру (метрики per-core видны сразу, без нажатий), память и своп. Внизу - подсказки по клавишам F1..F10. Чем htop лучше top: не требует root для запуска, показывает все ядра наглядно, перерисовывает плавно и работает мышью.

Ключевые клавиши htop linux:
  • F5 - дерево процессов (tree). Видно, кто кого породил: nginx и его воркеры, systemd и дети, docker и контейнерные процессы. Бесценно, чтобы понять структуру.
  • F3 - поиск по имени команды. Печатаешь "php" - прыгаешь по совпадениям клавишей F3.
  • F4 - фильтр. В отличие от поиска, прячет всё лишнее и оставляет только подходящее (живой grep по таблице).
  • F6 - выбрать колонку для сортировки.
  • F9 - послать сигнал (kill). Выбираешь процесс стрелками, жмёшь F9, выбираешь сигнал из списка. Можно выделить несколько процессов пробелом и прибить пачкой.
  • F2 - настройка (Setup): добавить или убрать шкалы сверху (в том числе PSI-метры и метр давления памяти), поменять цвета, выбрать и переставить колонки. Настройки сохраняются в ~/.config/htop/htoprc.
  • u - быстро отфильтровать процессы одного пользователя; F10 или q - выход.
В цветных шкалах CPU тоже зашита диагностика. По умолчанию: зелёный - обычные пользовательские процессы (us), красный - ядро (sy), синий - низкоприоритетные/nice. Если включить в Setup режим "Detailed CPU time", добавляются цвета для прерываний (irq/softirq), io-wait и steal. Легенду цветов всегда можно открыть прямо в htop клавишей F1 (h). Практический вывод тот же: если шкала ядра почти вся красная - ядро работает больше, чем твоё приложение, это повод задуматься (лишние syscalls, шторм прерываний).

Главные сигналы: io-wait (%wa), steal (%st) и PSI

Поля из строки %Cpu, ради которых вообще стоит открывать top или htop при тормозах.

%wa (io-wait). Процессор не занят, но и не отдыхает - он простаивает, потому что задачи ждут, пока диск или сеть отдадут данные. Если ты видишь id низкий, us и sy тоже невысокие, а wa скачет до 20-40 и выше - проблема не в процессоре, а в IO. Гадать бесполезно: дальше идёшь смотреть

Код: Выделить всё

iostat -x 1
(колонки %util, await, aqu-sz) и ищешь процессы в состоянии D в top/htop. Важный нюанс: wa - это доля, усреднённая по всем ядрам, поэтому на 32-ядерной машине даже сильная дисковая проблема даст скромный wa в 2-3%. На таких машинах честнее смотреть не на wa, а на PSI (см. ниже).

%st (steal). Виден только в виртуалке (на железе всегда 0). Это время, когда твоя VM хотела считать, но гипервизор отдал физическое ядро другому соседу. У тебя честно отняли такты. Если st стабильно держится на 5-10 и выше - ты, скорее всего, на переподписанном (oversold) хосте, и виноват не твой сервер, а провайдер. Скриншот строки %Cpu с высоким st - хороший аргумент в тикете хостеру. Эпизодические всплески st до 3-7 при общей низкой нагрузке - в облаке норма (особенно на burstable-тарифах вроде t-инстансов, где после исчерпания CPU-кредитов вас намеренно троттлят).

PSI (Pressure Stall Information) - актуально на 2026. Это более честная замена load average и io-wait, появилась в ядре 4.20 и сегодня доступна везде (cgroup v2 включён по умолчанию во всех современных дистрибутивах). Ядро прямо отвечает на вопрос "сколько времени задачи стояли в ожидании ресурса":

Код: Выделить всё

cat /proc/pressure/cpu
some avg10=0.00 avg60=0.12 avg300=0.45 total=...
cat /proc/pressure/memory
some avg10=3.20 avg60=1.10 avg300=0.40 total=...
full avg10=1.05 avg60=0.30 avg300=0.10 total=...
cat /proc/pressure/io
some avg10=12.40 avg60=8.70 avg300=5.10 total=...
Читается так: some - доля времени (в процентах) за последние 10/60/300 секунд, когда хотя бы одна задача стояла и ждала ресурс; full - доля времени, когда ВСЕ незанятые задачи стояли одновременно (полный затык). io some 12.40 в примере выше - это явный дисковый затор, причём виден сразу, без пересчёта на число ядер. htop 3.x умеет показывать PSI как отдельный метр - добавь его в Setup (F2). Для контейнеров и Kubernetes на 2026 PSI - это стандартный способ ловить перегрузку, поскольку давление считается отдельно по каждой cgroup.

atop, btop и что выбрать в 2026

atop - когда нужна история. top и htop показывают "сейчас", а тебе часто нужно "что было ночью в 3:40, когда всё легло". Ставь atop (

Код: Выделить всё

sudo apt install atop
) и включай сервис записи (

Код: Выделить всё

sudo systemctl enable --now atop
). Он пишет снимки системы на диск каждые N секунд, и потом историю можно проиграть как видеозапись:

Код: Выделить всё

atop -r /var/log/atop/atop_20260613
, листая интервалы клавишей t. atop единственный из всей четвёрки показывает нагрузку на диск и сеть в разрезе процессов - этого в top нет в принципе.

btop - современная альтернатива на 2026. Если top и htop про минимализм, то btop (наследник bashtop/bpytop, написан на C++) - это нарядный дашборд: графики CPU/памяти/сети/диска в динамике, рабочая мышь, графики IO по процессам, на десктопе - даже мониторинг GPU. Расплата - аппетит: htop занимает порядка 4 МБ памяти, btop около 20+ МБ. Поэтому практическое правило: на тесном VPS и в контейнере - htop (он есть почти везде и почти ничего не ест), на рабочей станции и жирном сервере, где хочется красивый обзор - btop, для разбора инцидента задним числом - atop.

Типичные грабли и заблуждения
  • "free мало, надо докупать память". Нет. Linux специально занимает свободную память под кэш. Смотри avail Mem, а не free.
  • "load average 2 - сервер умирает". Зависит от числа ядер. 2 на 8-ядерной машине - это скука. И помни: в Linux в load входит ещё и ожидание диска, так что высокий load при низком CPU - это часто IO, а не процессор.
  • Путают VIRT и RES. VIRT часто гигабайты у пустого процесса - это нормально. Память меряют по RES.
  • Не замечают %wa и игнорируют PSI. Грузят процессор оптимизациями, а тормозит диск. Сначала глянь wa и /proc/pressure/io.
  • Сразу шлют kill -9. Сигнал 9 (KILL) не даёт процессу закрыть файлы и сбросить буферы, можно повредить данные. Сначала 15 (TERM), и только если завис намертво - 9. И ещё: процесс в состоянии D сигналами не убивается вообще, пока не отпустит ядро (ждёт IO) - не паникуй, что kill "не работает".
Мини-лаба: повтори руками прямо сейчас
  • Узнай число ядер: . Запусти . Найди в шапке load average, id, wa, st и сравни load с числом ядер.
  • В top нажми по очереди P, потом M, потом 1, потом V. Увидь, как меняется сортировка, как раскрываются ядра и как строится дерево.
  • Создай нагрузку в соседнем терминале:

    Код: Выделить всё

    yes > /dev/null &
    . Найди этот процесс в top, посмотри его %CPU (около 100). Потом убей клавишей k сигналом 15 (или ).
  • Посмотри давление:

    Код: Выделить всё

    cat /proc/pressure/io
    и

    Код: Выделить всё

    cat /proc/pressure/cpu
    . Запиши avg10 для io.
  • Установи и открой htop. Нажми F5 (дерево), найди systemd и его детей. Нажми F4 и отфильтруй по "ssh". Зайди в F2 и добавь сверху метр Pressure Stall.
Контрольные вопросы
  • На 4-ядерном сервере load average 6.0, при этом %Cpu показывает id 80. Нагружен процессор или нет? Что тогда тянет load вверх?
  • В строке %Cpu видишь: id 70, wa 25. Куда смотреть дальше и почему дело скорее не в процессоре?
  • Что означает %st выше нуля, где его в принципе можно увидеть и о чём он говорит про хостинг?
  • Чем kill сигналом 15 отличается от сигнала 9, какой пробовать первым, и почему процесс в состоянии D может вообще не отреагировать на сигнал?
Что запомнить

Шапка top важнее таблицы: load average сравнивай с числом ядер и помни, что в Linux в него входит ещё и ожидание диска; память меряй по avail Mem и RES, а не по free и VIRT. Золотые поля строки %Cpu - %wa (ждём диск) и %st (украл гипервизор) - сразу подсказывают, твоя это вина или нет. На 2026 поверх этого смотри PSI (/proc/pressure/io|cpu|memory) - он точнее ловит перегрузку, особенно на многоядерных машинах и в контейнерах. top есть везде и хорош для быстрого взгляда; htop удобнее, его стоит установить на рабочие машины; btop - красивый дашборд для жирных хостов; atop незаменим, когда нужна история. Главное - не просто смотреть на цифры, а понимать, что норма, а что тревога, и куда копать дальше.
👍1 ❤️2 🔥4 😄 🤔2
Аватара пользователя
kubemaker
Сообщения: 1
Зарегистрирован: 15 май 2026, 21:25

Re: Интерактивный мониторинг: top и htop

Сообщение kubemaker »

Спасибо, наконец дошло про free и buff/cache - я реально память хотел докупать, а там кэш просто. И про avail Mem не знал. PSI вообще открытие, поставил метр в htop.
👍 ❤️ 🔥 😄 🤔
Аватара пользователя
Mademen
Сообщения: 1
Зарегистрирован: 18 май 2026, 21:57

Re: Интерактивный мониторинг: top и htop

Сообщение Mademen »

А вопрос: у меня на VPS st скачет 3-7 постоянно, это уже повод писать хостеру? Нагрузка вроде небольшая, но иногда лагает. Тариф burstable, если это важно.
👍3 ❤️1 🔥 😄 🤔
Ответить
← Предыдущая глава
Процессы Linux: ps, pstree и состояния процессов
Следующая глава →
Метрики процессов во времени: pidstat

Все главы курса «Диагностика и производительность Linux: логи, strace, perf и eBPF»

Поделиться темой: ✈ Telegram VK
Похожие запросы: ss как посмотреть открытые сокеты и соединенияhtop и top как читать и в чем разницапервые шаги мониторинга сервера linux для новичкаМониторинг и метрики nginxebpf и bpftrace с чего начать в linuxgit rebase: перебазирование

Вернуться в «Диагностика и производительность Linux: логи, strace, perf и eBPF»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость