Как найти скрипты, нагружающие CPU и RAM на Linux-сервере с помощью команды htop

Команда htop на Linux-сервере — одно из самых удобных средств для оперативного мониторинга процессов, которые чрезмерно нагружают процессор и оперативную память. Анализируя столбцы CPU%, MEM%, PID, USER, TIME+ и COMMAND, вы можете быстро определить, какой PHP, Python, Node.js, cron-задача, база данных или системный процесс «тормозит» сервер. Затем, проверив владельца процесса, путь к файлу и его назначение, можно безопасно принять меры.

Независимо от того, работает ли у вас shared-хостинг, VPS, VDS или выделенный сервер, внезапные торможения зачастую вызваны неконтролируемыми скриптами. Это может быть ошибочный плагин WordPress, бесконечный цикл в PHP-файле, интенсивная cron-задача, неоптимальный запрос к базе данных или взломанный веб-файл, способный за считанные минуты довести загрузку CPU до 100%. При росте потребления RAM сервисы начинают «зависать», падают соединения MySQL, сайты выдают ошибку 503, а ядро Linux может активировать OOM Killer и завершить некоторые процессы.

В этом руководстве мы подробно разберём установку htop, чтение его интерфейса, как выявлять скрипты, «съедающие» CPU и RAM, как по PID найти путь к файлу и как безопасно вмешиваться в работу процессов. Кроме того, затронем вопросы безопасности, проверку cron, анализ логов и рекомендации по оптимизации, чтобы проблемы не повторялись. Если вы часто сталкиваетесь с ограничениями ресурсов, рекомендуем ознакомиться с Пакеты VPS-серверов и Высокопроизводительный веб хостинг для выбора подходящей инфраструктуры.

Что такое htop и почему он удобнее, чем команда top?

htop — интерактивный терминальный мониторинг процессов в Linux. По функционалу похож на классический top, но обладает более наглядным интерфейсом, цветовой индикацией ресурсов, удобной сортировкой, поиском, фильтрацией и возможностями управления процессами. Благодаря этому htop часто становится первым инструментом системных администраторов при оперативной диагностике на боевом сервере.

С помощью htop вы можете в реальном времени видеть:

• Процент загрузки CPU каждым процессом
• Долю и объём используемой RAM
• Уникальный идентификатор процесса (PID)
• Пользователя, запустившего процесс
• Командную строку или название скрипта
• Время работы и приоритет процесса
• Среднюю нагрузку (load average), общий объём RAM, swap и использование ядер CPU

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

Установка htop: команды для разных дистрибутивов

В ряде современных дистрибутивов htop может не быть установлен по умолчанию. Если у вас есть root или sudo-доступ, установка займёт всего несколько секунд. Рекомендуется сначала обновить список пакетов, чтобы избежать ошибок, особенно на новых серверах.

Установка на Ubuntu и Debian

Для Ubuntu или Debian выполните:

sudo apt update

sudo apt install htop -y

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

Установка на AlmaLinux, Rocky Linux, CentOS и RHEL

На системах с RedHat-подобными дистрибутивами используйте:

sudo dnf install htop -y (для новых версий)

Для старых CentOS может потребоваться подключение репозитория EPEL:

sudo yum install epel-release -y

sudo yum install htop -y

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

Как читать экран htop: что означают столбцы?

При запуске htop в верхней части отображаются ядра CPU, RAM, swap, количество задач и потоков, load average и время работы системы. Внизу — список процессов. При диагностике особенно полезны следующие поля:

Важно помнить, что мгновенный скачок CPU не всегда означает проблему. Короткие всплески бывают при бэкапах, оптимизации изображений, очистке кеша или пиковом трафике. Настоящая проблема — это стабильное высокое потребление ресурсов, резкое увеличение load average и ухудшение отклика сервисов.

Как найти скрипты с высокой нагрузкой на CPU через htop

Чтобы отследить процессы с высокой загрузкой CPU, откройте htop и отсортируйте список по столбцу CPU% (клавиша F6 или клик мышкой по заголовку). Вверху окажутся самые «тяжёлые» процессы.

Шаг 1: Сортируем процессы по CPU%

Наблюдайте за процессами php-fpm, php, python3, node, java, mysqld или bash. Если какой-то из них постоянно в топе — запомните его PID и пользователя. В системах с несколькими ядрами значение CPU может превышать 100%, например 200% или 400%, что означает использование нескольких ядер.

Шаг 2: Запишите PID и USER

Запомните идентификатор и пользователя процесса. К примеру, процесс с PID 24819, USER — siteuser, COMMAND — php /home/siteuser/public_html/wp-cron.php — скорее всего связан с cron-задачей или механизмом WordPress. Если название команды слишком короткое, настройте htop на отображение полной командной строки или используйте ps для уточнения.

Шаг 3: Получаем полную команду по PID

Для подробного просмотра используйте:

ps -fp PID

Например:

ps -fp 24819

Это покажет, из какого файла запущен скрипт. Команда вроде php /home/user/public_html/index.php может означать нагрузку от обычного веб-запроса. Если путь включает плагины, например wp-content/plugins/неизвестный-плагин/task.php, проблема вероятно в плагине.

Шаг 4: Проверяем открытые файлы процесса

Команда lsof полезна, чтобы увидеть, какие файлы, библиотеки, логи и сетевые соединения открыты процессом:

lsof -p PID

Это помогает понять, какой сайт или каталог задействован. Если вы видите странные PHP-файлы в папках вроде /home/example/public_html/wp-content/uploads, это может быть признаком взлома. В таких случаях простого завершения процесса недостаточно — нужна очистка, смена паролей, обновление плагинов и комплексная проверка безопасности. Для настройки SSL и защищённых подключений посмотрите Решения по SSL сертификатам.

Как найти скрипты, потребляющие много RAM, с помощью htop

Проблемы с оперативной памятью часто менее очевидны, чем с CPU. При высоком потреблении RAM сервисы могут неожиданно падать, swap активно использоваться, а общая задержка возрастать. Сортировка по столбцу MEM% позволяет выявить процессы с наибольшим расходом памяти.

Понимание MEM%, RES и Swap

htop показывает MEM% — долю памяти, занятую процессом. В расширенном режиме видны VIRT, RES и SHR. Особое внимание уделяйте RES — реальному объёму физической памяти, занятой процессом. VIRT — виртуальная память, не всегда отражающая фактическое потребление.

Например, на VPS с 4 ГБ RAM если один PHP-процесс занимает 900 МБ RES — это ненормально. Если Node.js растёт с 200 МБ до 1.5 ГБ — возможно утечка памяти. В MySQL высокая память может быть связана с кешированием, что нормально, но требует оценки параметров и общей нагрузки.

Основные причины большого потребления RAM скриптами

• Бесконечные циклы в PHP, Python или Node.js
• Загрузка больших CSV, XML или JSON файлов в память целиком
• Неоптимизированные плагины и функции темы WordPress
• Обработка изображений, генерация PDF, конвертация видео
• Отсутствие кеширования и повторяющиеся тяжёлые запросы
• Множество одновременных запусков одного скрипта из-за бот-трафика или атак
• Долгоживущие сервисы с утечками памяти

В таких случаях команда kill поможет лишь временно. Для стабильного решения необходимо понять логику скрипта, причины запуска и почему память не освобождается.

Поиск, фильтрация и древовидное отображение в htop

Если на сервере сотни процессов, ручной поиск становится неудобным. htop предлагает полезные горячие клавиши: F3 для поиска, F4 для фильтрации и F5 для древовидного (tree) отображения. Последний режим особенно важен для понимания иерархии процессов — например, дочерние php-fpm, cron-задачи или сервисы под управлением supervisor, node.js и др.

Примеры удобных фильтров

• Введите php, чтобы отобразить только PHP-процессы
• python — фильтрация Python-скриптов
• wp-cron — отслеживание cron-задач WordPress
• node — просмотр Node.js приложений
• Фильтр по имени пользователя для выделения процессов одного аккаунта

Такие фильтры значительно экономят время на многопользовательских серверах. Если у вас десятки сайтов на одном сервере, анализ USER и пути к команде быстро выявит источник проблемы. Для управления доменами рекомендуем Проверка домена и регистрация.

Безопасный план действий при подозрительном PID

Обнаружив процесс с высоким потреблением ресурсов, может возникнуть желание сразу убить его командой kill -9. Однако такое решение может привести к потере данных, незавершённым операциям и сбоям сервисов. Лучше действовать поэтапно.

1. Документируем процесс

Запишите PID, USER, COMMAND, CPU%, MEM% и время. Сделайте скриншот экрана htop для последующего анализа. Это поможет сравнивать данные при повторных проблемах и предоставлять отчёты клиентам в агентствах, интернет-магазинах и корпоративных проектах.

2. Проверяем путь к файлу

С помощью ps -fp PID и lsof -p PID уточните путь запуска скрипта. Если файл находится в корне веб-сайта, изучите логи приложения: для WordPress — wp-content/debug.log, для веб-сервера — access и error логи, для PHP-FPM — slow log.

3. Пытаемся корректно завершить процесс

Отправьте стандартный сигнал завершения:

kill PID

Подождите несколько секунд и проверьте в htop, закрылся ли процесс. Если нет и ситуация критична, используйте:

kill -9 PID

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

4. Выясняем причину повторного запуска

Если процесс возобновляется сразу после завершения, причиной могут быть cron, systemd-сервисы, supervisor, веб-запросы или бот-трафик. Проверьте cron-задания (crontab -l), статус сервисов (systemctl status имя_сервиса) и логи веб-сервера. Для WordPress важно проверить настройки wp-cron и кеширования.

Сочетание выводов htop с анализом логов

htop показывает, что именно нагружает сервер, а логи — почему это происходит. Без их совместного анализа диагностика будет неполной. Например, процесс php-fpm может использовать 180% CPU, но без access логов невозможно определить, какой URL или бот запускает нагрузку.

Полезные для анализа логи:

• Access лог веб-сервера — показывает самые загруженные URL
• Error лог веб-сервера — ошибки PHP, права доступа, 500 ошибки
• PHP-FPM slow log — медленные PHP-скрипты и функции
• MySQL slow query log — тяжёлые SQL-запросы
• Auth или secure логи — подозрительные попытки входа
• Cron лог — время запуска запланированных задач

Например, если по PID с высокой нагрузкой в access логе фиксируется большое количество запросов к /wp-admin/admin-ajax.php, проблема может быть в плагине, боте или плохо настроенном AJAX. В таком случае стоит применять WAF, ограничение запросов, кеширование и оптимизацию плагинов. Подробнее о повышении скорости сайта читайте в Оптимизация скорости веб-сайта.

Как отличить нормальную нагрузку от проблемной?

Высокое потребление ресурсов не всегда признак сбоя. Важно учитывать аппаратную конфигурацию, уровень трафика, тип приложения и техническое обслуживание. Например, load average 6-8 длительное время на VPS с 2 ядрами — серьёзная проблема, а на выделенном сервере с 16 ядрами — это норма.

Это помогает отделить временные всплески от реальных проблем. Например, в период распродаж или обновлений на e-commerce сайте нагрузка может резко вырасти, но если это не мешает работе — переживать не стоит. В противном случае необходимо совместно оценить оптимизацию приложения и возможности сервера.

Безопасность: может ли скрипт, нагружающий ресурсы, быть вредоносным?

Высокое потребление CPU или RAM не всегда вызвано ошибкой — это может быть признаком взлома. Злоумышленники запускают спам-рассылки, майнинг криптовалют, прокси-трафик, DDoS-боты или бекдоры. В htop стоит насторожиться, если видны процессы под неизвестными пользователями, странные команды с бессмысленными именами, запущенные из /tmp, /dev/shm или папок uploads.

Признаки подозрительных процессов

• COMMAND с бессмысленными или случайными именами файлов
• Файлы из /tmp, /dev/shm или upload-папок
• Необычные perl, python или bash процессы
• Процессы с высокой активностью по внешним сетевым соединениям
• Множество процессов, запущенных одним пользователем за короткое время
• Недавние неожиданные изменения в веб-файлах

В таких случаях сначала соберите доказательства (выводы команд), проверьте права доступа, изолируйте вредоносные файлы, смените все пароли в панели и CMS, обновите плагины, темы и ядро. Рекомендуется включить двухфакторную аутентификацию и убрать лишние права записи для повышения безопасности.

Лучшие практики для предотвращения повторных проблем с производительностью

Обнаружить проблему с помощью htop — только первый шаг. Главное — не допустить её повторения. Следующие рекомендации помогут существенно снизить риски CPU и RAM-проблем на Linux-серверах:

• Настройте memory_limit, max_execution_time и pm.max_children в PHP в соответствии с мощностью сервера
• Используйте кеширование в WordPress, Joomla и других CMS
• Удалите ненужные плагины, темы и модули
• Оптимизируйте тяжелые SQL-запросы с помощью журнала медленных запросов MySQL
• Не запускайте все cron-задачи одновременно — распределяйте по времени
• Применяйте ограничения запросов, настраивайте robots.txt и firewall для защиты от ботов
• Регулярно ротируйте логи и контролируйте их размер, чтобы не перегружать диск и память
• Мониторьте метрики сервера не только во время кризисов, но и регулярно

Если после оптимизаций проблемы остаются, возможно, причина — рост трафика, расширение приложения или недостаток ресурсов хостинга. В этом случае стоит рассмотреть масштабируемый VPS, увеличение RAM, более быстрые NVMe-диски или выделенный сервер. Для анализа и выбора подходящего решения посетите Пакеты хостинга и решения для корпоративных серверов.

Пример: всплеск нагрузки CPU на WordPress сайте

Рассмотрим реальный сценарий. На VPS с 4 ядрами и 8 ГБ RAM размещено несколько WordPress сайтов. Пользователи жалуются на замедления и ошибки 502. При запуске htop load average достигает 12, все ядра загружены, а вверху списка много php-fpm процессов одного пользователя.

С помощью фильтра по пользователю (F4) выделяется нужный аккаунт. Записывается PID самого ресурсоёмкого процесса. Через ps -fp PID определяется, что это php-fpm воркер. lsof -p PID показывает открытый файл /home/site/public_html/wp-content/plugins/example-importer/import.php. В access логах в это же время фиксируются запросы администратора и частые AJAX-вызовы.

Решение: остановить импорт, отключить планировщик плагина, разбить импорт большого объёма данных на части, увеличить max_execution_time в PHP, переключиться с wp-cron на системный cron. В итоге load average падает с 12 до 1.8, загрузка CPU нормализуется, время ответа сайта значительно улучшается. Этот пример демонстрирует, как htop в связке с ps, lsof и логами помогает эффективно локализовать и устранить проблему.

Типичные ошибки при работе с htop

• Заводить процесс только по верхнему результату и не исследовать причину
• Принимать VIRT за реальное потребление RAM
• Считать кеширование MySQL проблемой
• Использовать kill -9 как первый метод завершения
• Обвинять приложение или пользователя без проверки логов
• Интерпретировать load average без учёта количества ядер
• Игнорировать проверку целостности файлов при подозрении на взлом

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

Часто задаваемые вопросы

Что делает команда htop на Linux-сервере?

htop отображает в реальном времени информацию о процессах: их загрузку CPU, использование RAM, пользователя, PID и команду запуска. Это позволяет быстро находить скрипты, нагружающие сервер.

Как с помощью htop найти скрипт, который нагружает CPU?

Отсортируйте процессы по CPU%, запомните PID и пользователя подозрительных процессов. Затем используйте ps -fp PID и lsof -p PID для уточнения пути к файлу и характеристик скрипта.

Что учитывать при анализе потребления RAM — MEM% или VIRT?

MEM% и особенно RES (реальное использование физической памяти) более информативны. VIRT показывает виртуальную память и не всегда отражает текущие затраты RAM.

Правильно ли сразу завершать проблемный процесс через kill -9?

Чаще нет. Сначала стоит понять, что это за процесс, проверить пути и пробовать стандартное завершение (kill PID). kill -9 — крайняя мера, если процесс не завершается и угрожает стабильности сервера.

Всегда ли высокая загрузка CPU указывает на атаку?

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

В итоге команда htop — это быстрый и удобный способ выявить скрипты, нагружающие CPU и RAM на Linux-сервере. Для максимальной эффективности используйте htop совместно с анализом PID, выводом lsof, проверкой cron и изучением логов. Если проблемы с ресурсами повторяются, оценивайте как оптимизацию ПО, так и возможности инфраструктуры. При необходимости сравните хостинг, VPS и SSL-решения Hostragons без коммерческого давления, чтобы выбрать оптимальный вариант для вашего проекта.