htop: полный гайд по мониторингу процессов

htop — одна из тех утилит, которые почти всегда устанавливают на новый Linux-сервер первыми. Она показывает процессы, загрузку CPU, память, swap, потоки, дерево процессов и позволяет быстро понять, кто «съел» ресурсы прямо сейчас.

В отличие от классического top, утилита htop интерактивнее: по процессам можно перемещаться стрелками, сортировать таблицу клавишами, искать нужный процесс, фильтровать вывод, менять nice, отправлять сигналы и завершать зависшие задачи без ручного ввода kill.

Для разработчика и DevOps-инженера htop полезен в момент инцидента: сайт начал отвечать медленно, API отдаёт 502/503, база грузит CPU, воркеры расплодились после деплоя. Внешний мониторинг доступности вроде Statuser с заданным интервалом проверки покажет, что сайт перестал отвечать или начал падать, а htop поможет уже на сервере быстро сузить причину до конкретного процесса или группы процессов.

Что такое htop и чем он полезен

htop — консольный интерактивный монитор процессов для Unix-подобных систем. Он читает данные из /proc, системных счётчиков ядра и показывает состояние сервера в режиме, близком к реальному времени.

Главная задача htop — ответить на вопросы:

• какие процессы потребляют больше всего CPU;
• хватает ли памяти;
• используется ли swap;
• сколько потоков и задач запущено;
• какие процессы находятся в состоянии сна, выполнения, ожидания I/O;
• какой пользователь запустил процесс;
• какой командой процесс был стартован;
• что можно безопасно завершить или приоритизировать.

htop не заменяет полноценный мониторинг метрик, логов и алертов: у него нет долгой истории и графиков за неделю. Зато он отлично работает как «лупа» для живой диагностики: подключились по SSH, запустили htop, увидели текущую картину.

Типичные случаи, где htop особенно удобен:

1) Сервер внезапно стал медленным — можно быстро проверить, не забил ли один процесс все ядра CPU.

2) Приложение расходует память — видно рост RES, использование swap и возможный риск срабатывания OOM Killer.

3) После деплоя стало больше процессов — дерево процессов помогает понять, кто породил лишние воркеры.

4) Нужно аккуратно завершить задачу — можно выбрать процесс и отправить ему SIGTERM, а не сразу использовать жёсткий SIGKILL.

5) Нужно сравнить поведение сервисов — например, nginx, postgres, redis, node, java, python или фоновых воркеров.

Если нужна история потребления ресурсов и сравнение периодов, лучше смотреть в сторону atop, glances или полноценной системы мониторинга. У Statuser уже есть отдельный материал про atop и glances для расширенного мониторинга ресурсов сервера.

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

На большинстве дистрибутивов htop есть в стандартных репозиториях.

Для Debian и Ubuntu:

sudo apt update
sudo apt install htop

Для RHEL, CentOS Stream, Fedora:

sudo dnf install htop

Для старых CentOS с yum:

sudo yum install htop

Для Arch Linux:

sudo pacman -S htop

Для Alpine Linux:

sudo apk add htop

Для macOS через Homebrew:

brew install htop

Запуск:

htop

Если нужно видеть процессы всех пользователей и иметь возможность управлять системными процессами, запускайте от root или через sudo:

sudo htop

Полезные варианты запуска:

1) Показать только процессы конкретного пользователя

htop -u www-data

Так удобно смотреть процессы веб-сервера, PHP-FPM или отдельного пользователя деплоя.

2) Запустить с задержкой обновления

htop -d 20

Значение задаётся в десятых долях секунды. 20 означает обновление примерно раз в 2 секунды.

3) Открыть дерево процессов

htop -t

Дерево удобно при разборе процессов, порождённых systemd, supervisord, pm2, gunicorn, php-fpm и другими менеджерами.

4) Показать справку

htop --help

После запуска htop занимает весь терминал. Выйти можно клавишей F10 или q.

Как читать интерфейс htop

Экран htop делится на три основные зоны: верхняя панель с метриками, таблица процессов и нижняя строка горячих клавиш.

Верхняя панель обычно показывает:

• загрузку CPU по ядрам;
• использование памяти;
• использование swap;
• количество задач;
• количество потоков;
• load average;
• uptime сервера.

Показатели CPU отображаются полосами. Если ядер много, htop может показывать их компактно или группировать — это настраивается через F2.

Таблица процессов обычно содержит такие колонки:

• PID — идентификатор процесса;
• USER — пользователь, от имени которого запущен процесс;
• PRI — приоритет планировщика;
• NI — значение nice;
• VIRT — виртуальная память процесса;
• RES — физическая память в RAM;
• SHR — разделяемая память;
• S — состояние процесса;
• %CPU — потребление CPU;
• %MEM — доля памяти;
• TIME+ — суммарное CPU-время;
• COMMAND — команда запуска.

Состояния процессов в колонке S:

1) R — running — процесс выполняется или готов выполняться на CPU.

2) S — sleeping — процесс спит и ждёт события: сеть, диск, таймер, ввод-вывод.

3) D — uninterruptible sleep — процесс ждёт I/O и не реагирует на обычные сигналы. Часто указывает на проблемы с диском, NFS или файловой системой.

4) Z — zombie — процесс завершился, но родитель ещё не забрал его код завершения.

5) T — stopped — процесс остановлен сигналом или отладчиком.

Панель памяти нужно читать аккуратно: Linux активно использует свободную память под page cache, поэтому «занятая память» не всегда означает проблему. Подробнее про аварийное завершение процессов ядром — в материале про OOM Killer в Linux.

load average вверху показывает среднюю длину очереди задач за 1, 5 и 15 минут — это не «проценты загрузки CPU». Как правильно сопоставлять эти числа с количеством ядер, подробно разобрано в статье что такое load average в Linux.

Сортировка, поиск, фильтры и дерево процессов

Основная сила htop — быстрые интерактивные действия без длинных команд.

Полезные клавиши:

• F6 — выбрать колонку сортировки;
• P — сортировать по CPU;
• M — сортировать по памяти;
• T — сортировать по времени CPU;
• F3 — поиск;
• F4 — фильтр;
• F5 — дерево процессов;
• F2 — настройки;
• F1 — справка;
• Space — отметить процесс;
• U — снять все отметки;
• F9 — отправить сигнал;
• F7 / F8 — изменить nice;
• F10 или q — выход.

Сценарии использования:

1) Найти самый прожорливый процесс по CPU — нажмите P. Вверху таблицы окажутся процессы с максимальным %CPU. Значение выше 100% — нормально для многопоточных процессов, использующих несколько ядер.

2) Найти потребителя памяти — нажмите M. Смотрите не только %MEM, но и RES: VIRT может быть большим из-за mmap и зарезервированного адресного пространства, не всегда означая реальное потребление RAM.

3) Найти конкретный сервис — нажмите F3 и введите nginx, postgres, node, java, php-fpm или имя вашего бинарника. Поиск перемещает курсор к совпадению.

4) Оставить на экране только нужное — нажмите F4 и введите фильтр. Например, node покажет только процессы, в команде которых есть node.

5) Понять родителя процесса — нажмите F5. Дерево покажет, кто запустил процесс: systemd, shell, supervisord, pm2, master-процесс веб-сервера или другой менеджер.

6) Отметить несколько процессов — используйте Space, затем примените действие ко всем отмеченным. Это удобно, но опасно: перед отправкой сигнала проверьте, что отмечены именно нужные процессы.

Для сортировки можно использовать и мышь, если терминал поддерживает mouse mode: клик по заголовку колонки меняет сортировку, а прокрутка колесом перемещает список.

Управление процессами: сигналы, nice и приоритеты

htop позволяет не только смотреть, но и управлять процессами. Делать это нужно аккуратно, особенно на продакшене.

Главное действие — отправка сигнала через F9. После выбора процесса нажмите F9, затем выберите сигнал.

Самые частые сигналы:

1) SIGTERM (15) — вежливая просьба завершиться. Процесс может обработать сигнал, закрыть соединения, сохранить состояние, завершить дочерние процессы. Обычно начинать нужно с него.

2) SIGKILL (9) — принудительное завершение ядром. Процесс не может обработать этот сигнал. Используйте, если SIGTERM не помог и вы понимаете риск: незавершённые транзакции, битые временные файлы, потерянные задачи.

3) SIGHUP (1) — часто используется для перечитывания конфигурации: некоторые демоны после SIGHUP перезагружают конфиг без полного рестарта.

4) SIGSTOP и SIGCONT — остановить и продолжить процесс. Полезно редко, но может пригодиться при диагностике.

Изменение nice доступно через F7 и F8. Чем выше nice, тем «вежливее» процесс к остальным и тем ниже его приоритет CPU. Чем ниже nice, тем выше приоритет. Для отрицательных значений обычно нужны права root.

Примеры:

• nice 10 — процесс получает меньше CPU при конкуренции;
• nice 0 — обычный приоритет;
• nice -5 — повышенный приоритет, использовать осторожно.

Не стоит лечить системные проблемы постоянным понижением nice у конкурентов. Если веб-приложение регулярно забивает CPU, лучше искать причину: неэффективный запрос, бесконечный цикл, слишком много воркеров, отсутствие лимитов, GC-паузы, проблемы с пулом соединений.

Если сервис управляется systemd, часто правильнее не убивать отдельный процесс, а выполнить:

sudo systemctl restart имя-сервиса

или посмотреть его статус:

sudo systemctl status имя-сервиса

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

CPU, память и load average: как не ошибиться с выводами

htop легко открыть, увидеть красную полосу CPU или занятую память и сделать неверный вывод. Несколько правил помогают избежать ложной диагностики.

1) Высокий CPU не всегда проблема

Если сервер выполняет фоновые задачи, пересобирает кэш, обрабатывает очередь или сжимает изображения, высокая загрузка CPU может быть ожидаемой. Проблема начинается, когда CPU насыщен, очередь растёт, latency увеличивается, а пользователи видят ошибки.

Смотрите на сочетание:

• %CPU у процессов;
• load average;
• количество ядер;
• наличие процессов в R;
• задержки приложения;
• ошибки в логах;
• внешние симптомы доступности.

2) Большой VIRT не равен утечке памяти

У Java, Node.js, PostgreSQL, браузерных движков и приложений с mmap виртуальная память может быть большой. Для реального давления на RAM чаще полезнее RES, swap и поведение во времени.

3) Swap — тревожный сигнал, но не всегда авария

Небольшое использование swap может оставаться после прошлой нагрузки. Плохо, если swap активно растёт, сервер начинает тормозить, процессы уходят в ожидание I/O, а интерактивность падает.

4) Состояние D требует отдельного внимания

Если много процессов в D, CPU может быть не главным узким местом: процессы ждут диск, сеть или файловую систему. В таком случае стоит смотреть iostat, dmesg, логи ядра, состояние дисков, NFS, сетевые mounts.

5) Один процесс может показывать больше 100% CPU

В htop %CPU часто считается относительно одного ядра. Многопоточный процесс на 8-ядерной машине может показывать 300–600%, если реально использует несколько ядер.

6) Потоки могут запутать картину

В настройках можно включать и выключать отображение пользовательских и kernel threads. Если показываются потоки, один сервис может занимать много строк. Это полезно для диагностики, но мешает беглому обзору.

Если нужно понять, почему процесс открыл много файлов или держит порт, htop лучше дополнить lsof. Для этого есть отдельная инструкция: как использовать lsof для диагностики открытых файлов и портов. А если процесс зависает на системных вызовах, пригодится strace: что такое strace и как отлаживать системные вызовы.

Практические сценарии диагностики через htop

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

1) Сайт отдаёт 502 или 503

Откройте htop, отсортируйте по CPU (P) и памяти (M), проверьте: жив ли backend-процесс, не забил ли CPU один воркер, не ушёл ли сервис в swap, не слишком ли много дочерних процессов, не перезапускается ли приложение циклически. Если nginx работает как reverse proxy, а backend — node, gunicorn, php-fpm, uvicorn или java, дерево процессов (F5) часто показывает, кто реально жив, а кто остался zombie.

2) После деплоя выросла нагрузка

Сравните процессы нового релиза с ожидаемой моделью: сколько воркеров должно быть и сколько реально запущено, не стартовал ли старый процесс параллельно с новым, не появились ли лишние cron-задачи, не дублируется ли consumer очереди. Если приложение запускается через pm2, systemd, supervisord, Docker или Kubernetes node, htop покажет процессы на конкретной машине, но не объяснит всю оркестрацию — зато быстро выявит локальный перекос.

3) Сервер «тормозит», но CPU не загружен

Смотрите на swap, процессы в D, load average, количество потоков и подозрительные фоновые задачи. Если CPU свободен, а load высокий, часто причина в I/O wait или блокировках. htop покажет начало картины, дальше нужны дисковые и сетевые инструменты.

4) Подозрение на утечку памяти

Отсортируйте по памяти (M) и наблюдайте за RES у процесса. Одного снимка мало: процесс может штатно держать кэш. Признаки проблемы: RES монотонно растёт, swap начинает использоваться активнее, приложение замедляется, в логах появляются ошибки выделения памяти, процессы убиваются ядром. При подозрении на OOM смотрите dmesg, journalctl и системные логи.

5) Зависшая фоновая задача

Найдите процесс через F3 или фильтр F4, посмотрите TIME+, состояние и команду запуска. Если задача висит дольше допустимого, сначала попробуйте SIGTERM. Если это cron-задача, импорт, миграция или обработчик очереди, проверьте, не держит ли он lock, файл или соединение с базой.

6) Непонятный процесс от неизвестного пользователя

Смотрите USER, COMMAND, путь запуска, родителя в дереве. Если процесс подозрительный, не спешите удалять файлы: зафиксируйте PID, команду, пользователя, открытые соединения и файлы. Здесь пригодятся lsof, ss, журналы и аудит.

Настройка htop под себя

htop можно настроить через F2. Настройки сохраняются в пользовательском конфиге. В зависимости от версии путь может быть таким:

• ~/.config/htop/htoprc;
• ~/.htoprc.

Обычно вручную редактировать файл не нужно: интерфейс настроек удобнее.

Что стоит настроить:

1) Колонки таблицы

Добавьте или уберите поля в зависимости от задач. Часто полезны: PPID (PID родительского процесса), PGRP (группа процессов), STATE (состояние), IO_RATE (если поддерживается сбор I/O-метрик), STARTTIME (время запуска процесса), CWD (рабочая директория, если доступна в вашей версии).

2) Отображение потоков

Можно скрывать kernel threads и userland threads, чтобы таблица была компактнее. Для диагностики многопоточных приложений, наоборот, отображение потоков помогает увидеть перекос внутри процесса.

3) Цветовые схемы и индикаторы

Можно выбрать стиль отображения CPU, памяти и swap. На серверах с большим количеством ядер компактный режим читабельнее.

4) Единицы измерения

Проверьте, как отображается память: в MiB, GiB или автоматическом формате. Это уменьшает риск ошибиться при беглом просмотре.

5) Дерево по умолчанию

Если вы часто разбираете веб-стек с master/worker-моделью, дерево процессов может быть удобнее обычного списка.

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

Но не стоит полагаться только на локальный конфиг. Если команда работает с инцидентами совместно, договоритесь об общих правилах: какие сигналы использовать, когда можно делать SIGKILL, какие сервисы перезапускать только через systemctl, что фиксировать перед вмешательством.

Ограничения htop и чем его дополнять

htop хорош для интерактивной диагностики, но у него есть ограничения.

1) Нет полноценной истории

Если нагрузка была 20 минут назад, а сейчас всё спокойно, htop уже не покажет прошлое состояние. Для истории нужны Prometheus, Grafana, Zabbix, Netdata, atop, системные логи или облачный мониторинг.

2) Нет контекста приложения

htop покажет, что процесс node потребляет CPU, но не скажет, какой endpoint, tenant, SQL-запрос или задача очереди вызвали нагрузку. Для этого нужны application metrics, трассировки, профилирование и логи.

3) Контейнеры могут искажать восприятие

На хосте htop показывает процессы всех контейнеров как обычные процессы Linux. Это полезно, но без понимания Docker/Kubernetes можно перепутать, к какому контейнеру относится процесс. Иногда лучше дополнить вывод docker stats, crictl, kubectl top или cgroup-метриками.

4) Не видно внешнюю доступность

Процесс может выглядеть живым, CPU — нормальным, память — свободной, но сайт недоступен из-за DNS, TLS, сети, балансировщика, firewall или внешнего провайдера. Поэтому локальная диагностика должна сочетаться с проверками снаружи. Например, Statuser проверяет сайт с заданным интервалом и присылает уведомление о сбое; это помогает понять момент начала инцидента, а htop — проверить состояние сервера в этот момент.

5) Не заменяет алерты

Никто не сидит в htop круглосуточно. Для продакшена нужны автоматические проверки, метрики, пороги, алерты и понятный on-call-процесс. Для базового понимания внешних проверок можно почитать материал что такое uptime monitoring и как он работает.

Лучший подход — использовать htop как быстрый интерактивный инструмент в связке с другими источниками: метрики CPU, RAM, I/O, сети; логи приложения и systemd; трассировки и профили; проверка доступности сайта; мониторинг баз данных и очередей; история деплоев.

Тогда htop становится не единственным источником правды, а удобной точкой входа в расследование.

FAQ

Можно ли завершать процессы прямо из htop?

Да. Выберите процесс, нажмите F9 и отправьте сигнал. Обычно сначала используйте SIGTERM, а SIGKILL оставляйте для случаев, когда процесс не завершается.

Почему процесс в htop показывает больше 100% CPU?

Так бывает у многопоточных процессов. Значение часто считается относительно одного ядра, поэтому процесс может использовать несколько CPU и показывать 200%, 400% и больше.

Чем htop отличается от top?

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

Нужно ли ставить htop на продакшен-сервер?

Обычно да, если это разрешено политиками безопасности. Утилита лёгкая и полезная при инцидентах. Но она не заменяет системный мониторинг, алерты и историю метрик.