Чем заменить top, ps и netstat при диагностике сервера 1С

Пользователи жалуются на задержки в 1С. Вы подключаетесь по SSH, открываете top и видите высокую нагрузку. Но экран не отвечает, кто ждёт диск, сколько процессорного времени забрал гипервизор и какие соединения держит rphost.

За один сеанс SSH причину можно сузить до четырёх направлений: процессор, диск, виртуализация или сеть. Для этого хватит htop, pidstat, iotop, mpstat, ss и журнала atop. Постоянную панель стоит ставить, только если задержки повторяются.

htop находит подозрительный процесс

Начните с htop. Он показывает процессы в интерактивном списке, поддерживает поиск, сортировку и дерево родительских связей. Эти функции описаны в обзорах Forpes и It’s FOSS.

Нажмите F5, чтобы открыть дерево процессов. Так проще отделить процессы кластера 1С от PostgreSQL, веб-сервера и фоновых служб Linux. Устройство ragent, rmngr и rphost описано в руководстве по устройству кластера 1С.

Клавиша F6 меняет поле сортировки. Сначала отсортируйте процессы по загрузке CPU, затем по памяти. Поиск по F3 пригодится, если на хосте работают сотни процессов.

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

У htop есть предел. Он показывает текущую картину, но не восстановит всплеск, который закончился до вашего подключения. Ещё он не заменяет отдельную проверку дискового ввода-вывода, виртуализации и сокетов.

От общего процесса — к CPU, диску и гипервизору

Сначала сравните load average с числом логических процессоров:

uptime
nproc

Forpes предлагает считать превышение load average над числом из nproc признаком нагрузки. Это лишь сигнал для следующей проверки. Средняя нагрузка включает не только вычисления, поэтому по одному uptime нельзя обвинить процессор.

Дальше найдите процесс и проверьте его отдельной командой.

Вывод из таблицы простой: htop находит кандидата, а pidstat, iotop и mpstat проверяют разные причины задержки. Одна команда не заменяет остальные.

Проверьте CPU конкретного процесса

pidstat входит в пакет sysstat. Команда ниже выводит показатели процесса каждую секунду:

pidstat -p 1842 1

Замените 1842 на PID нужного rphost, PostgreSQL или другого процесса. Для одновременной проверки CPU, памяти и диска лучше запустить три отдельных команды: их вывод проще сопоставить по времени.

pidstat -p 1842 1
pidstat -r -p 1842 1
pidstat -d -p 1842 1

Если нагрузку создаёт один rphost, продолжайте проверку на уровне кластера и сеансов. Высокий CPU у PostgreSQL ведёт уже к запросам, блокировкам и обслуживанию базы.

Найдите процесс, который обращается к диску

Команда iotop -oP оставляет только процессы с текущим дисковым вводом-выводом:

sudo iotop -oP

Опция -P группирует вывод по процессам, а -o скрывает тех, кто сейчас не читает и не пишет. Такой фильтр удобнее общего списка, когда на сервере работают 1С, PostgreSQL и резервное копирование.

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

Отделите гостевую нагрузку от дефицита CPU на хосте

В виртуальной машине часть процессорного времени может забрать гипервизор. mpstat показывает это время в колонке %steal:

mpstat -P ALL 1 3

Команда делает три выборки с интервалом в одну секунду по всем логическим процессорам. Это заданные параметры команды, а не оценка производительности сервера.

Если одновременно растут load average и %steal, проверьте нагрузку физического хоста и лимиты виртуальной машины. Переносить базу или менять параметры PostgreSQL до этой проверки рано: задержка может находиться за пределами гостевой ОС.

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

ss отвечает на конкретный сетевой вопрос

netstat знаком многим администраторам, но на сервере с большим числом соединений удобнее ss. Он входит в пакет iproute2, который ставят современные дистрибутивы Linux.

Начните со слушающих TCP- и UDP-сокетов:

sudo ss -tulpn

Эта команда показывает адрес, порт и процесс. Сведения о сокетах чужого пользователя требуют root-доступа — то же ограничение действует у netstat с ключом -p.

Для общей картины выполните:

ss -s

Когда интересуют только установленные TCP-соединения, сузьте вывод:

sudo ss -tnp state established

Фильтр по порту сокращает список ещё сильнее:

ss -tn '( dport =:443 )'

Вместо 443 подставьте порт сервера 1С, PostgreSQL, Apache или прокси, который проверяете. ss также фильтрует соединения по состоянию, адресу, интерфейсу и диапазону портов.

Чтобы посчитать строки, уберите заголовок ключом -H:

ss -Htn state established | wc -l

Без -H команда wc -l посчитает заголовок как ещё одно соединение.

Почему ss быстрее на длинном списке соединений

По описанию MyUnix.org, netstat читает текстовые псевдофайлы /proc/net/tcp, /proc/net/udp и /proc/net/unix. ss получает структурированные данные ядра через интерфейс NETLINK_SOCK_DIAG.

MyUnix.org проверил обе команды на Rocky Linux 9.3 с ядром 5.14.0, iproute2 6.2.0 и net-tools 2.10. На сервере работало около 48 000 TCP-соединений. Медиана для netstat -ant составила 3,8 секунды, для ss -ant — 0,28 секунды.

Это чужой тест с названной системой и набором версий, а не замер нашей лаборатории. На вашем сервере время будет другим. Практический вывод не зависит от конкретного результата: встроенные фильтры ss сокращают объём данных ещё до обработки вывода в shell.

ss не заменяет все сетевые инструменты. Если нужно узнать потребление трафика по процессам, Forpes предлагает nethogs. Для разбора пакетов нужны tcpdump или Wireshark, а не ещё один вариант вывода сокетов.

Пропущенный скачок ищите в atop

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

По данным Forpes и It’s FOSS, atop сохраняет историю потребления ресурсов. В конфигурации из обзора интервал записи по умолчанию составляет 10 секунд.

На Debian и Ubuntu пакет устанавливается так:

sudo apt install atop
sudo systemctl enable --now atop

Перед первым инцидентом проверьте, что служба запущена:

systemctl status atop

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

Для одного инцидента хватит консольных команд. Для пропущенного скачка нужен atop. Постоянный сбор оправдан, когда задержку приходится сопоставлять между несколькими хостами или слоями системы.

Когда ставить веб-панель

glances -w запускает веб-режим Glances. По материалам LinuxVox и Forpes, панель собирает на одном экране CPU, память, диски, сеть, процессы, датчики и контейнеры.

glances -w

В конфигурации из обзора интерфейс открывается на порту 61208. Не публикуйте его наружу без ограничения доступа. Способ защиты зависит от вашей сети, прокси и принятой схемы администрирования.

Netdata Agent подходит, когда нужна секундная детализация и история. Beszel использует схему hub + agent: один узел собирает сведения с нескольких серверов.

Не ставьте постоянную панель только ради красивого графика. Она требует обновлений, контроля доступа, хранения данных и собственного наблюдения. На одном сервере с редкими инцидентами журнал atop создаёт меньше работы.

Cockpit решает другую задачу: через него смотрят состояние сервера, журналы, сеть и хранилища, а также управляют службами. Monit следит за процессами и может автоматически их перезапускать. ntopng, LibreNMS и OpenNMS рассчитаны прежде всего на сетевой мониторинг.

Если задержки нужно связывать с сеансами 1С, блокировками PostgreSQL и ресурсами Linux, продолжите по порядку сопоставления процессов 1С, СУБД и хоста. Общего графика CPU для такой диагностики мало.

Комплект для одного сеанса SSH

Установите четыре пакета заранее, а не во время жалобы:

sudo apt install htop sysstat iotop atop
sudo systemctl enable --now atop

Для Fedora и совместимых дистрибутивов используйте пакетный менеджер dnf. Перед установкой сверяйте имена пакетов в репозитории своей версии Linux.

Сохраните этот порядок проверки:

1. Откройте htop, найдите процесс и его место в дереве.
2. Проверьте выбранный PID через pidstat.
3. Запустите iotop -oP, если подозреваете диск.
4. Посмотрите %steal через mpstat, если 1С работает в виртуальной машине.
5. Сузьте сетевой вывод через ss, а пропущенный скачок найдите в atop.

Граница выбора проходит по частоте и масштабу проблемы. Для одного сервера и ручной диагностики хватает консольного набора. Для исчезающих событий добавьте историю. Для повторяющихся задержек между Linux, PostgreSQL и 1С нужен постоянный сбор метрик.