Как посмотреть нагрузку на сервер linux

Обновлено: 04.07.2024

Объем памяти, размер кеша, скорость чтения и записи на диск, скорость и доступность вычислительной мощности – это ключевые элементы, влияющие на производительность любой инфраструктуры.

Данное руководство ознакомит с базовыми понятиями мониторинга CPU. Вы узнаете, как использовать утилиты uptime и top, чтобы узнать о нагрузке и использовании ЦП.

Требования

  • Сервер Linux.
  • Утилиты uptime и top должны быть установлены по умолчанию. Если это не так, установите их вручную.

Основные понятия

Прежде чем приступить к работе с утилитами, нужно понять, как измеряется использование ЦП и к каким результатам нужно стремиться.

Загрузка и использование ЦП

Загрузка (CPU Load) и использование процессора (CPU Utilization) – два разных способа взглянуть на использование вычислительной мощности компьютера.

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

Использование ЦП оценивает исключительно занятость кассиров и не знает, сколько клиентов в очереди.

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

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

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

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

Ненормированные и нормированные значения

В одной процессорной системе общая емкость всегда равна 1. В многопроцессорной системе данные могут отображаться двумя разными способами. Суммарная емкость всех процессоров рассчитывается как 100% независимо от количества процессоров, такое значение считается нормированным. Другой вариант предлагает считать каждый процессор как единицу, так что 2-процессорная система в полном объеме имеет емкость 200%, 4-процессорная система в полном объеме имеет мощность 400% и т. д.

Чтобы правильно интерпретировать загрузку или использование CPU, нужно знать количество процессоров на сервере.

Отображение информации о ЦП

Чтобы узнать количество процессоров, можно использовать команду nproc с опцией –all. Без этого флага команда отобразит количество обрабатывающих блоков, доступных для текущего процесса, что будет меньше общего количества процессоров.

В большинстве современных дистрибутивов Linux также можно использовать команду lscpu, которая отображает не только количество процессоров, но и архитектуру, имя модели, скорость и многое другое:

Знание точного количества процессоров важно для интерпретации результатов тех или иных утилит.

Оптимальные значения загрузки и использования ЦП

Оптимальное значение использования ЦП зависит от того, какую работу должен выполнять сервер. Стабильно высокое использование процессора негативно влияет на отзывчивость системы. Часто приложениям и пакетным заданиям с интенсивными вычислениями необходим весь или почти весь объем ЦП. Однако, если система должна обслуживать веб-страницы или поддерживать интерактивные сеансы сервисов (например, SSH), тогда может понадобиться свободная вычислительная мощность.

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

Мониторинг ЦП

Существует множество инструментов для получения данных о состоянии ЦП системы. Мы рассмотрим две команды: uptime и top. Обе утилиты являются частью стандартной установки большинства популярных дистрибутивов Linux и обычно используются для исследования загрузки и использования ЦП.

Примечание: Следующие примеры выполнены на 2-ядерном сервере.

Утилита uptime

Команда uptime позволяет отследить загрузку процессора. Она может быть полезна, если система медленно реагирует на интерактивные запросы (вероятно, ей не хватает системных ресурсов).

Утилита uptime сообщает следующие данные:

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

uptime
14:08:15 up 22:54, 2 users, load average: 2.00, 1.37, 0.63

В этом примере команда была запущена в 14:08 на сервере, который работал почти 23 часа. При запуске uptime подключились два пользователя. Этот сервер имеет 2 процессора. За минуту до запуска команды средняя загрузка процессора была 2,00, что означает, что в течение этой минуты процессоры использовали в среднем две задачи, а ожидающих задач не было. Среднее значение загрузки з а5 минут указывает на то, что в течение некоторого интервала времени один из процессоров бездействовал около 60% времени. Среднее за 15 минут значение указывает на то, что было доступно больше времени обработки. Вместе эти три значения показывают увеличение загрузки за последние пятнадцать минут.

Утилита uptime сообщает полезные средние значения загрузки ЦП, но для того, чтобы получить более подробную информацию, нужно использовать top.

Утилита top

Как и uptime, утилита top доступна как в Linux, так и в Unix-системах, но помимо отображения средних значений нагрузки для заданных временных интервалов она предоставляет информацию о потреблении ЦП в реальном времени, а также другие полезные показатели производительности. Если uptime запускается и сразу завершает работу, top работает на переднем плане и регулярно обновляется.

Заглавный блок

Первые пять строк содержат сводную информацию о процессах на сервере:

top - 18:31:30 up 1 day, 3:17, 2 users, load average: 0.00, 0.00, 0.00
Tasks: 114 total, 1 running, 113 sleeping, 0 stopped, 0 zombie
%Cpu(s): 7.7 us, 0.0 sy, 0.0 ni, 92.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.1 st
KiB Mem : 4046532 total, 3238884 free, 73020 used, 734628 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 3694712 avail Mem

Первая строка почти идентична выводу утилиты uptime. Здесь показаны средние значения за одну, пять и пятнадцать минут. Эта строка отличается от вывода uptime только тем, что вначале указывается утилита top и время последнего обновления данных.

Вторая строка предоставляет краткий обзор состояния задач: общее количество процессов, количество запущенных, спящих, остановленных и зависших процессов.

Третья строка говорит об использовании ЦП. Эти цифры нормируются и отображаются в процентах (без символа %), так что все значения в этой строке должны составлять до 100% независимо от количества процессоров.

Четвертая и пятая строки сообщают об использовании памяти и swap соответственно.

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

В нижеприведенном заглавном блоке среднее значение загрузки за одну минуту превышает число процессоров на .77, что указывает на короткую очередь с небольшим временем ожидания. Общая емкость процессора используется на 100%, и есть много свободной памяти.

top - 14:36:05 up 23:22, 2 users, load average: 2.77, 2.27, 1.91
Tasks: 117 total, 3 running, 114 sleeping, 0 stopped, 0 zombie
%Cpu(s): 98.3 us, 0.2 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.2 si, 1.3 st
KiB Mem : 4046532 total, 3244112 free, 72372 used, 730048 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 3695452 avail Mem
. . .

Давайте рассмотрим подробнее все компоненты строки CPU.

  • us, user: время на un-niced процессы пользователя. Эта категория относится к пользовательским процессам, которые были запущены без явного приоритета планирования. Системы Linux используют команду nice для установки приоритета планирования процесса. «un-niced» означает, что приоритет по умолчанию не менялся с помощью nice. Значения user и nice учитывают все пользовательские процессы. Высокое использование ЦП в этой категории может указывать на неконтролируемый процесс. Вывод в таблице процессов может определить, действительно ли это так.
  • sy, system: системные процессы. Большинство приложений имеют как пользовательские компоненты, так и компоненты ядра. Когда ядро Linux создает системные вызовы, проверяет привилегии или взаимодействует с устройствами от имени приложения, здесь отображается использование процессора. Когда процесс выполняется не ядром, он будет отображаться либо в показателе user, либо в nice, если его приоритет был задан с помощью nice.
  • ni, nice: niced процессы пользователя. Как и user, это поле отображает задачи, не связанные с ядром. В отличие от user, приоритет планирования для этих задач был установлен с помощью nice. Уровень приоритета (niceness) процесса указан в четвертом столбце таблицы процессов в заголовке NI. Процессы со значением niceness от 1 до 20 имеют пониженный приоритет. Такие процессы, потребляющие много процессорного времени, обычно не создают проблем, потому что задачи с повышенным приоритетом получат вычислительную мощность своевременно. Однако, если задачи с повышенным приоритетом (между -1 и -20) занимают непропорциональное количество CPU, они могут легко повлиять на отзывчивость системы. Обратите внимание, что многие процессы с самым высоким приоритетом планирования (-19 или -20 в зависимости от системы) порождаются ядром для выполнения важных задач, которые влияют на стабильность системы. Если вы не уверены, что точно знаете все процессы, указанные в выводе, лучше исследуйте их, но не останавливайте.
  • Id, idle: время, затраченное на обработчик простоя ядра. Этот показатель отображает процент времени, в течение которого ЦП был доступен и простаивал. Считается, что система разумно использует ЦП, если сумма user, nice и idle близка к 100%.
  • wa, IO-wait: время ожидания завершения ввода-вывода. Показатель сообщает, когда процессор начал операцию чтения или записи и ожидает завершения операции ввода-вывода. Задачи чтения и записи для удаленных ресурсов (таких как NFS и LDAP) будут также учитываться. Как и в строке idle, прыжки здесь считаются нормой. Но если показатель сообщает о частых или продолжительных обработках, это может указывать на зависшую задачу или потенциальную проблему с жестким диском.
  • hi: время на бслуживание аппаратных прерываний. Это время, затрачиваемое на физические прерывания, отправленные на процессор с периферийных устройств (дисков и аппаратных сетевых интерфейсов). Если значение аппаратного прерывания велико, одно из периферийных устройств может работать неправильно.
  • si: время, затраченное на обслуживание программных прерываний. Программные прерывания отправляются процессами, а не физическими устройствами. В отличие от аппаратных прерываний, которые происходят на уровне ЦП, программные прерывания происходят на уровне ядра. Если этот показатель сообщает о высоком использовании вычислительной мощности, исследуйте процессы, которые используют CPU.
  • st: время, которое использовал гипервизор. Значение steal сообщает, как долго виртуальный процессор ожидает ответа физического процессора, когда гипервизор обслуживает свои задачи или другой виртуальный процессор. По сути, объем использования ЦП в этом поле указывает, сколько мощности для обработки виртуальной машины готово к использованию, но недоступно приложению, поскольку оно используется физическим хостом или другой виртуальной машиной. Как правило, нормой значения steal считается до 10% в течение коротких периодов времени. Большее значение steal в течение более длительного периода времени указывает на то, что физический сервер имеет больший спрос на CPU, чем он может предоставить.

Таблица процессов

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

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9966 8host 20 0 9528 96 0 R 99.7 0.0 0:40.53 stress
9967 8host 20 0 9528 96 0 R 99.3 0.0 0:40.38 stress
7 root 20 0 0 0 0 S 0.3 0.0 0:01.86 rcu_sched
1431 root 10 -10 7772 4556 2448 S 0.3 0.1 0:22.45 iscsid
9968 root 20 0 42556 3604 3012 R 0.3 0.1 0:00.08 top
9977 root 20 0 96080 6556 5668 S 0.3 0.2 0:00.01 sshd
.

Столбец %CPU представлен как процентное значение, но он не нормируется, поэтому в этой двухъядерной системе общее количество всех значений в таблице процессов должно составлять до 200%, если оба процессора полностью используются.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10081 8host 20 0 9528 96 0 R 50.0 0.0 0:49.18 stress
10082 8host 20 0 9528 96 0 R 50.0 0.0 0:49.08 stress
1439 root 20 0 223832 27012 14048 S 0.2 0.7 0:11.07 snapd
1 root 20 0 39832 5868 4020 S 0.0 0.1 0:07.31 systemd

Заключение

Теперь вы умеете работать с утилитами uptime и top и интерпретировать их вывод.

В данной статье пойдет речь о мониторинге нагрузки, именно, в контексте веб-сервера. Мы не будем особо заострять внимание на проверке производительности системы, как, например, командами top, htop, free и так далее.

Нагрузка на сервер

Анализ нагрузки стоит начать с общих метрик — потребление процессорного времени, памяти, нагрузки на сеть и дисковую систему.

Нагрузка по процессам

Проверить, нагружен ли сервер, а также понять, какой именно процесс больше всего потребляет ресурсов можно с помощью команд:

* по сути, все 3 вышеперечисленные команды выдают одну и туже информацию в разном виде. Какой-то из них может оказаться удобнее пользоваться. Утилита top встроена в систему, для использования остальных необходимо установить одноименные пакеты.

Оперативная память

Для определения объема свободной и занимаемой памяти можно воспользоваться командой:

* предыдущие команды тоже показывали утилизацию памяти, но кому-то команда free может показаться нагляднее.

Нагрузка на диск

Для определения нагрузки на дисковую систему, используем утилиту iotop. Сначала ее нужно установить.

а) На системы Debian / Ubuntu:

apt-get install iotop

б) На системы Red Hat / CentOS:

yum install iotop

После выполняем следующую команду:

Сетевая активность

Для измерения нагрузки на сеть необходимо установить утилиту nload.

а) В CentOS / Red Hat:

yum install nload

б) В Ubuntu / Debian:

apt-get install nload

После установки, запускаем утилиту командой:

* в данном примере будет запущена статистика для использования сетевого интерфейса eth0.

Что грузит систему

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

Использование lsof

lsof — утилита командной строки, которая отображает какие файлы используются процессами. Она позволит определить, к каким скриптам идет обращение со стороны веб-сервера. Для начала, необходимо установить lsof.

а) В CentOS / Red Hat:

yum install lsof

б) В Ubuntu / Debian:

apt-get install lsof

Теперь можно выполнить следующие команды:

* первая команда покажет, к каким файлам обращается apache, вторая — php-fpm (часто можно увидеть в связке с nginx).

Анализ error-логов

Анализ логов ошибок позволит не только обнаружить проблемы в работе сайта, но и найти причину его медленной работы. По умолчанию, логи находятся в каталоге /var/log. Если мы не меняли расположение логов, запускаем следующие команды:

tail -f /var/log/nginx/error.log

* лог ошибок nginx.

tail -f /var/log/php-fpm/error.log

* лог ошибок php-fpm.

* лог ошибок apache в CentOS.

tail -f /var/log/apache2/error_log

* лог ошибок apache в Ubuntu.

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

Статистика веб-сервера

Для веб-серверов можно воспользоваться служебной страницей просмотра статуса. Она может показать статистику запросов к веб-серверу.

Apache

По умолчанию, server-status не активен. Создаем конфигурационный файл.

Для CentOS / Red Hat:

Для Ubuntu / Debian:

* где 2 — используемая версия apache.

В открытый конфигурационный файл добавим:

<VirtualHost *:80>
servername 111.111.111.111
<Location /server-status>
Sethandler server-status
</Location>
</VirtualHost>

<Location /server-status>
SetHandler server-status
</Location>

* где 111.111.111.111 — IP-адрес нашего веб-сервера; 80 — порт, на котором слушает apache.
* в данном примере мы прописали два варианта просмотра статистики: первый — обращение в браузере к серверу по IP-адресу + /server-status; второй — обращение к любому сайту + /server-status. Разные способы оправданы для разных настроек самих сайтов и используемых CMS.

Проверим корректность внесенных данных и перезапустим веб-сервер apache:

NGINX + PHP-FPM

Открываем конфигурационный файл nginx:

.
server listen 80;
server_name 111.111.111.111;
location /server-status stub_status on;
>
>
.

* где 111.111.111.111 — IP-адрес нашего веб-сервера.

Проверяем корректность настройки и перезапускаем nginx:

systemctl restart nginx

Открываем браузер и заходим на страницу 111.111.111.111/server-status. Мы должны увидеть статистику использования сервера:

Статистика использования NGINX

Теперь настроим статистику для php-fpm. В конфигурационном файле nginx в нашу директиву server добавим:

* обратите внимание на закомментированную строку и строку под ней. В зависимости от того, как настроен php-fpm (слушает на порту или через сокетный файл) необходимо настроить nginx. В данном примере подразумевается, что php-fpm слушает на 9000 порту.

Открываем конфигурационный файл php-fpm:

Снимаем комментарий со следующей строки:

Проверяем настройку nginx, перезапускаем его и php-fpm:

systemctl restart nginx

systemctl restart php-fpm

Открываем браузер и заходим на страницу 111.111.111.111/server-status. Мы должны увидеть статистику использования сервера:

Статистика использования PHP-FPM

Долгие запросы

С помощью длительных запросов к веб-серверу или СУБД можно сделать выводы о том, что является узким местом в работе сервиса.

MySQL / MariDB

Для начала, воспользуемся инструкцией, чтобы настроить ведение лога медленных запросов (для MySQL или MariaDB).

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

PHP-FPM

Открываем конфигурационный файл:

Редактируем следующие параметры:

request_slowlog_timeout = 10s
slowlog = /var/log/php-fpm/www-slow.log

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


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

Простые утилиты Linux показывают текущее потребление памяти для каждого процесса, нагрузку на CPU, свободное место на диске и статистику по трафику.

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

Использование ресурсов

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


Непосредственно перед таблицей приводится некоторая общая статистика, включая среднюю нагрузку на CPU за последнюю минуту, 5 минут и 15 минут. Также показано потребление памяти, файла подкачки и состояние процессов.

Список обновляется в реальном времени: можете вывести его на второй монитор и наблюдать постоянно.

Хотя утилита top поставляется почти с каждым дистрибутивом, в большинстве репозиториев также доступна для скачивания улучшенная версия htop .

Установка htop на Ubuntu:


Здесь мы видим почти такую же выдачу, но с подсветкой разными цветами и более интерактивную:


Верхняя часть здесь яснее и лучше организована.

Вот некоторые ключи для более эффективного использования htop :

  • M: сортировка процессов по использованию памяти
  • P: сортировка процессов по использованию CPU
  • ?: справка
  • k: прекратить текущие/помеченные процессы
  • F2: настройка (здесь можно выбрать опции для отображения)
  • /: поиск процессов

Сетевой трафик

nethogs

nethogs — самая простая утилита для просмотра, сколько трафика приходится на каждую службу. На Ubuntu утилита устанавливается следующей командой:


Затем её можно запустить без ключей. Выдача простая:


Есть всего несколько опций для изменения выдачи:

  • m: переключение между kb/s, kb, b, mb
  • r: сортировка по полученному трафику.
  • s: сортировка по отправленному трафику
  • q: выход

IPTraf

IPTraf — ещё один способ мониторинга сетевого трафика, с большим количеством опций. Установка на Ubuntu:


Эта утилита предлагает выбрать один из интерактивных интерфейсов:


Например, для обзора всего сетевого трафика выбираем первый пункт меню:


Чтобы IP-адреса резолвились в домены, нужно в конфигурации выбрать пункт 'Reverse DNS lookups'.

Вместе просмотром трафика по портам есть вариант просмотра трафика по сервисам (опция 'TCP/UDP service names'). С обеими включёнными опциями выдача будет выглядеть примерно так:


Есть ещё несколько других интерфейсов, которые можете изучить самостоятельно.

netstat

Утилита netstat — очень гибкий и мощный инструмент для сбора сетевой информации.

По умолчанию netstat выдаёт список открытых сокетов:


Если добавить опцию -a , он покажет список всех портов:


Флаги -t или -u фильтруют TCP- или UDP-соединения, соответственно. Флаг -s выводит статистику. Для постоянного обновления выдачи нужно запускать команду с ключом -c .

Место на диске

Стандартная утилита для просмотра информации о смонтированных разделах — это df . Она выводит список подключенных устройств и информацию о занятом месте.


По умолчанию выдача в байтах, что не очень удобно. Параметр -h активирует выдачу в мегабайтах и гигабайтах:


Для просмотра всего места на всех дисках добавляем опцию --total .

Утилита df позволяет быстро получить общий обзор. Для более детальной информации лучше подходит программа du , которая анализирует текущую директорию и любые поддиректории. Выдача по умолчанию выглядит так:


Опять же, более удобная для восприятия выдача включается ключом -h .

Просмотр размеров файлов и директорий включается флагом -a , общий итог — флагами -c (подробности и сумма) и -s (только сумма).

Улучшенные версии

Улучшенные версии df и du называются pydf и ncdu, на Ubuntu они устанавливаются командами apt-get install pydf и apt-get install ncdu . Они организуют красивую выдачу в псевдографике с расцветкой:

Здесь можно перемещаться по файловой системе клавишами со стрелками.

Использование памяти

Самый простой способ просмотра текущего использования оперативной памяти — команда free . Выдача без опций выглядит таким образом:


Запуск с ключом -m генерирует выдачу в мегабайтах.

Средняя строка -/+ buffers/cache показывает значение используемой памяти минус сумма буферов/кэша, а также количество свободной памяти плюс сумма буферов/кэша.

Дело в том, что Linux как большинство современных ОС пытается использовать максимальный объём доступной оперативной памяти под буферы и кэш. Поэтому имеет значение вторая строка, которая показывает реальный объём потенциально доступной оперативной памяти для приложений, если игнорировать буферы и кэш. Этот объём будет освобождён автоматически, если он понадобится для приложений.

vmstat

Команда vmstat выводит различную информацию о системе, включая память, файл подкачки, операции ввода-вывода и нагрузку на CPU.


В первой колонке r указано количество активных процессов, во второй — количество процессов в состоянии непрерываемого ожидания.

Колонки si и so показывают объём памяти, которая считывается из файла подкачки и записывается в него, соответственно.

Далее показано количество блоков, которые получены или отправлены на устройство блочного ввода вывода (bi, bo), количество прерываний в секунду, включая таймер (in), количество переключений контекста в секунду (cs) и статистика по CPU: процент времени, затраченного на обработку кода в пользовательском пространстве (us), на обработку кода ядра (sy), в спящем состоянии (id) и ожидании ввода-вывода (wa), а также времени, «украденного» у виртуальной машины (st), то есть когда виртуальный CPU ожидает действия реального CPU, когда гипервизор обслуживает другой виртуальный процессор.

Флаг -S M активирует выдачу в мегабайтах. Запуск с опцией -s показывает общую статистику.

Если вам необходимо круглосуточно отслеживать состояние сервера (память, CPU, свободное место, производительность, время отклика и проч.), то можно воспользоваться бесплатным или платным сервисом мониторинга. Таких сервисов много, вот небольшой список в алфавитном порядке:










    (бесплатная адаптация Nagios Core)





    (бесплатная версия называется Nagios Core)











    (бесплатно)


    (бесплатный системный монитор)

Для примера, рассмотрим три относительно популярных сервиса для мониторинга.

SolarWinds Server and Application Monitor

Один из самых продвинутых серверных мониторов на рынке — SolarWinds Server and Application Monitor (SAM). Хотя инструмент устанавливается только на Windows Server 2016+, но может отслеживать любое оборудование, в том числе Linux-серверы.


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


Программа лучше подходит для крупных корпораций. Заявлена совместимость с серверами Dell PowerEdge, HP ProLiant, IBM eServer xSeries, Dell PowerEdge Blade, HP BladeSystem, Microsoft Windows Server и VMware vSphere. В то же время SAM мониторит и облачные инстансы AWS и Azure.


Он показывает статистику по времени отклика, загрузке CPU, памяти и др. Отслеживается производительность отдельных приложений: встроена поддержка более 1200 разных приложений. Также проверяется состояние оборудования: использование CPU, нагрузка на диски, энергопитание, статус вентиляторов и т. д. Статусы кодируются цветом от зелёного до красного, чтобы было легко оценить здоровье системы с первого взгляда.


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


Обычно у таких сервисов имеется бесплатный пробный период, а стоимость может зависеть от набора используемой функциональности. Здесь тоже есть пробный период, а стоимость SolarWinds Server and Application Monitor начинается от 1275 евро в минимальной функциональности.

Navicat Monitor

Другой пример — Navicat Monitor, который специализируется на мониторинге баз данных. Он поддерживает MySQL, MariaDB, SQL Server, а также облачные СУБД, такие как Amazon RDS, Amazon Aurora, Oracle Cloud, Google Cloud и Microsoft Azure.



Стандартный вид



Компактный вид

Монитор отслеживает время выполнения конкретных запросов, запуская их с заданным интервалом.



Кроме запросов к БД, периодически отправляются и другие запросы к серверам для мониторинга показателей производительности системы ввода-вывода, сети и проч. Собирается статистика по использованию CPU, загрузке памяти и другие стандартные метрики.



Архитектура Navicat Monitor не предусматривает установку программного обеспечения на объекты мониторинга

Минимальная цена Navicat Monitor — $32,99 за один токен в месяц (один токен соответствует мониторингу одного сервера или четырёх баз Azure). Есть полнофункциональная пробная версия на 14 дней.

Zabbix

Zabbix — это бесплатный опенсорсный инструмент, который отслеживает состояние сети, приложений и самого сервера. Поставляется с готовыми шаблонами для мониторинга популярных серверов и ОС, включая HP, IBM, Lenovo, Dell, Linux-серверы, Ubuntu и Solaris. За годы существования Zabbix сообщество подготовило шаблоны для различных сценариев.


Ключевые модули Zabbix следят за нагрузкой CPU, использованием памяти, уровнем ошибок ввода-вывода, свободным местом на диске, статусе вентиляторов, температурой и характеристиками системы питания. Сетевой модуль проверяет трафик, доступность сети, уровень потерь пакетов, качество TCP-соединений и пропускную способность маршрутизаторов.

Zabbix ведёт список установленного программного обеспечения и версий прошивок, чтобы сигнализировать о несанкционированной установке ПО.


Системный администратор может запрограммировать в Zabbix уведомления по произвольным условиям, а также изменить важность действующих уведомлений. На панели управления можно добавить пользователей — и направлять каждому из них определённые типы уведомлений, а скрипты автоматизации позволяют автоматически заводить задачи и присваивать их сотрудникам.

Благодаря функции удалённого доступа и управления Zabbix можно назвать хорошим инструментом администрирования сервера.

Надёжный сервер в аренду и правильный выбор тарифного плана позволят меньше отвлекаться на неприятные уведомления мониторинга — всё будет работать без сбоев и с очень высоким uptime!

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

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

Как посмотреть загрузку процессора в Linux

1. Утилита htop

Самый простой способ узнать насколько процессор загружен в данный момент - воспользоваться утилитой htop. Она показывает не только процент загрузки по каждому ядру процессора отдельно, но и позволяет найти процессы, которые нагружают систему больше всего. Для установки htop в Debian или Ubuntu выполните:

sudo apt install htop

А в CentOS или REHL:

sudo yum install htop

Главное окно программы выглядит вот так:


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

2. Файл /proc/loadavg

Если надо сориентироваться какая была нагрузка на процессор в последнее время, тут htop не поможет. Можно воспользоваться файлом /proc/loadavg. Его создаёт ядро и в нём содержится информация о средней нагрузке за одну, пять и пятнадцать минут. Но обратите внимание, данные, находящиеся в этом файле не такие однозначные. Во первых, это не проценты, во вторых, они отображают не нагрузку на процессор, а нагрузку на систему в целом.

Первые три значения в этом файле означают среднее количество процессов или потоков, которые выполняются, находятся в очереди на выполнение или ждут завершения операций ввода/вывода за 1, 5 и 15 минут. Вот:


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

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

3. Утилита mpstat

Утилита mpstat позволяет посмотреть подробную статистику по использованию процессора. Можно посмотреть не только информацию по каждому из ядер, но и куда используются ресурсы - на ввод/вывод, ядро или программы пространства пользователя. Для установки программы в Ubuntu или Debian выполните:

sudo apt install sysstat

В CentOS или REHL:

sudo yum install sysstat

Для просмотра общей информации выполните такую команду:


А для просмотра подробностей по каждому ядру процессора используйте опцию -P с параметром ALL:


Вот значения колонок в выводе этой программы:

  • CPU - номер ядра процессора;
  • %usr - потребление программами пространства пользователя;
  • %nice - потребление ресурсов в процентах программами в пространстве пользователя с повышенным приоритетом;
  • %sys - потребление ресурсов процессора ядром;
  • %iowait - затраты на ожидание ввода/вывода;
  • %irq - ресурсы, потраченные на прерывания для работы с аппаратным обеспечением;
  • %soft - ресурсы, потраченные на программные прерывания;
  • %steal - украденные процессорные ресурсы, актуально для виртуальных машин;
  • %guest - ресурсы, потраченные на работу виртуального процессора;
  • %idle - неиспользованные ресурсы.

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

4. Команда nmon

Утилита nmon позволяет выводить данные, в виде, похожем на htop, но только немного подробнее. Для установки её в Ubuntu и Debian выполните:

sudo apt install nmon

Для установки в CentOS или REHL:

sudo yum install nmon

После запуска надо нажать кнопку c для того чтобы отобразить информацию о нагрузке на ядра процессора:


Здесь кроме наглядной шкалы по каждому ядру выводится информация в процентах по таким показателям:

  • User% - ресурсы, потраченные программами в пространстве пользователя;
  • Sys% - ресурсы, потраченные ядром;
  • Wait% - ресурсы, которые идут на ожидание ввода/вывода;

Здесь уже можно сориентироваться насколько всё загружено и в чём проблема.

5. CoreFreq

Если всей полученной ранее информации о производительности вам мало, можно воспользоваться утилитой CoreFreq. Её нет в официальных репозиториях, поэтому придется собирать программу из исходников. Но зато она имеет свой модуль ядра, который устанавливает свои счетчики производительности в ядре и возвращает утилите наиболее подробные данные. Сначала установите необходимые компоненты. В Ubuntu:

sudo apt install dkms git libpthread-stubs0-dev

В CentOS или REHL:

sudo yum group install 'Development Tools'

Затем скачайте репозиторий утилиты с GitHub и соберите её:

Загрузите модуль ядра такой командой:

sudo insmod corefreqk.ko

Запустите её сервис:

Затем запускайте программу:


Вверху программы отображается информация о процессоре, ниже шкалы с загруженностью каждого ядра, а её ниже различные показатели по каждому ядру: частота - Freq, ускорение - Turbo, C0-C7 - значения состояний C-State процессора. В данном примере, большинство ядер процессора работают на минимальной частоте и большую часть времени находятся в состоянии C1. Это состояние означает, что ядро не активно, но может в любой момент перейти к выполнению инструкций. Состояние C0 - означает, что ядро активно и выполняет какие-то действия.

С помощью этой утилиты вы сможете узнать максимально подробную информацию о загрузке процессора и о самом процессоре в целом.

Выводы

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

Читайте также: