LFCS: мониторинг использования ресурсов процессов Linux и установка ограничений процессов для каждого пользователя — часть 14
В связи с недавними изменениями в целях сертификационного экзамена LFCS, вступившими в силу с 2 февраля 2016 года, мы добавляем необходимые статьи в серию LFCS, опубликованную здесь. Чтобы подготовиться к этому экзамену, вам настоятельно рекомендуется также пройти серию LFCE.
Каждый системный администратор Linux должен знать, как проверить целостность и доступность оборудования, ресурсов и ключевых процессов. Кроме того, установка ограничений ресурсов для каждого пользователя также должна быть частью его набора навыков.
В этой статье мы рассмотрим несколько способов убедиться, что система, как аппаратное, так и программное обеспечение, работает правильно, чтобы избежать потенциальных проблем, которые могут привести к неожиданному простою производства и потере денег.
Статистика процессоров отчетов Linux
С помощью mpstat вы можете просматривать действия каждого процессора в отдельности или системы в целом, как в виде однократного снимка, так и динамически.
Чтобы использовать этот инструмент, вам необходимо установить sysstat:
yum update && yum install sysstat [On CentOS based systems]
aptitutde update && aptitude install sysstat [On Ubuntu based systems]
zypper update && zypper install sysstat [On openSUSE systems]
Узнайте больше о sysstat и его утилитах в разделе «Изучите Sysstat и его утилиты» mpstat, pidstat, iostat и sar в Linux.
После установки mpstat используйте его для создания отчетов со статистикой процессоров.
Чтобы отобразить 3 глобальных отчета об использовании ЦП (-u) для всех ЦП (как указано -P ALL) с интервалом в 2 секунды. , делать:
mpstat -P ALL -u 2 3
Пример вывода
Linux 3.19.0-32-generic (linux-console.net) Wednesday 30 March 2016 _x86_64_ (4 CPU)
11:41:07 IST CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
11:41:09 IST all 5.85 0.00 1.12 0.12 0.00 0.00 0.00 0.00 0.00 92.91
11:41:09 IST 0 4.48 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 94.53
11:41:09 IST 1 2.50 0.00 0.50 0.00 0.00 0.00 0.00 0.00 0.00 97.00
11:41:09 IST 2 6.44 0.00 0.99 0.00 0.00 0.00 0.00 0.00 0.00 92.57
11:41:09 IST 3 10.45 0.00 1.99 0.00 0.00 0.00 0.00 0.00 0.00 87.56
11:41:09 IST CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
11:41:11 IST all 11.60 0.12 1.12 0.50 0.00 0.00 0.00 0.00 0.00 86.66
11:41:11 IST 0 10.50 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 88.50
11:41:11 IST 1 14.36 0.00 1.49 2.48 0.00 0.00 0.00 0.00 0.00 81.68
11:41:11 IST 2 2.00 0.50 1.00 0.00 0.00 0.00 0.00 0.00 0.00 96.50
11:41:11 IST 3 19.40 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 79.60
11:41:11 IST CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
11:41:13 IST all 5.69 0.00 1.24 0.00 0.00 0.00 0.00 0.00 0.00 93.07
11:41:13 IST 0 2.97 0.00 1.49 0.00 0.00 0.00 0.00 0.00 0.00 95.54
11:41:13 IST 1 10.78 0.00 1.47 0.00 0.00 0.00 0.00 0.00 0.00 87.75
11:41:13 IST 2 2.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 97.00
11:41:13 IST 3 6.93 0.00 0.50 0.00 0.00 0.00 0.00 0.00 0.00 92.57
Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
Average: all 7.71 0.04 1.16 0.21 0.00 0.00 0.00 0.00 0.00 90.89
Average: 0 5.97 0.00 1.16 0.00 0.00 0.00 0.00 0.00 0.00 92.87
Average: 1 9.24 0.00 1.16 0.83 0.00 0.00 0.00 0.00 0.00 88.78
Average: 2 3.49 0.17 1.00 0.00 0.00 0.00 0.00 0.00 0.00 95.35
Average: 3 12.25 0.00 1.16 0.00 0.00 0.00 0.00 0.00 0.00 86.59
Чтобы просмотреть ту же статистику для определенного ЦП (ЦП 0 в следующем примере), используйте:
mpstat -P 0 -u 2 3
Пример вывода
Linux 3.19.0-32-generic (linux-console.net) Wednesday 30 March 2016 _x86_64_ (4 CPU)
11:42:08 IST CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
11:42:10 IST 0 3.00 0.00 0.50 0.00 0.00 0.00 0.00 0.00 0.00 96.50
11:42:12 IST 0 4.08 0.00 0.00 2.55 0.00 0.00 0.00 0.00 0.00 93.37
11:42:14 IST 0 9.74 0.00 0.51 0.00 0.00 0.00 0.00 0.00 0.00 89.74
Average: 0 5.58 0.00 0.34 0.85 0.00 0.00 0.00 0.00 0.00 93.23
Вывод приведенных выше команд показывает следующие столбцы:
CPU: номер процессора в виде целого числа или слово all в виде среднего значения для всех процессоров.%usr: процент использования ЦП при запуске приложений пользовательского уровня.%nice: то же, что%usr, но с приоритетом nice.%sys: процент загрузки ЦП при выполнении приложений ядра. Сюда не входит время, потраченное на обработку прерываний или работу с оборудованием.%iowait: процент времени, когда данный ЦП (или все) простаивал, в течение которого на этом ЦП была запланирована ресурсоемкая операция ввода-вывода. Более подробное объяснение (с примерами) можно найти здесь.%irq: процент времени, затраченного на обслуживание аппаратных прерываний.%soft: То же, что%irq, но с программными прерываниями.%steal: процент времени, потраченного на вынужденное ожидание (кражу или кражу времени), когда виртуальная машина в качестве гостя «завоевывает» внимание гипервизора, конкурируя за процессор(ы). Это значение должно быть как можно меньшим. Высокое значение в этом поле означает, что виртуальная машина зависает или скоро это произойдет.%guest: процент времени, затраченного на работу виртуального процессора.%idle: процент времени, когда ЦП не выполняли никаких задач. Если вы наблюдаете низкое значение в этом столбце, это указывает на то, что система находится под большой нагрузкой. В этом случае вам нужно будет более внимательно изучить список процессов, о чем мы поговорим через минуту, чтобы определить, что его вызывает.
Чтобы подвергнуть процессор несколько высокой нагрузке, выполните следующие команды, а затем выполните mpstat (как указано) в отдельном терминале:
dd if=/dev/zero of=test.iso bs=1G count=1
mpstat -u -P 0 2 3
ping -f localhost # Interrupt with Ctrl + C after mpstat below completes
mpstat -u -P 0 2 3
Наконец, сравните с выводом mpstat в «нормальных» обстоятельствах:
Как вы можете видеть на изображении выше, ЦП 0 находился под большой нагрузкой в течение первых двух примеров, о чем свидетельствует столбец %idle.
В следующем разделе мы обсудим, как идентифицировать эти ресурсоемкие процессы, как получить о них дополнительную информацию и как предпринять соответствующие действия.
Отчеты о процессах Linux
Чтобы составить список процессов, отсортировав их по использованию ЦП, мы будем использовать известную команду ps с -eo (чтобы выбрать все процессы в пользовательском формате) и --sort (чтобы указать собственный порядок сортировки), например:
ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu
Приведенная выше команда покажет только PID, PPID, команду, связанную с процессом, а также процент использования ЦП и ОЗУ, отсортированный по проценту использования ЦП в порядке убывания. . Вот первые несколько строк вывода, выполненных во время создания файла .iso:
Как только мы определили интересующий процесс (например, с PID=2822), мы можем перейти к /proc/PID (/proc/2822 в данном случае) и выполните листинг каталога.
В этом каталоге хранятся несколько файлов и подкаталогов с подробной информацией об этом конкретном процессе во время его работы.
Например:
/proc/2822/ioсодержит статистику ввода-вывода для процесса (количество символов и байтов, прочитанных и записанных, среди прочего, во время операций ввода-вывода)./proc/2822/attr/currentпоказывает текущие атрибуты безопасности SELinux процесса./proc/2822/cgroupописывает группы управления (сокращенно cgroups), к которым принадлежит процесс, если включена опция конфигурации ядра CONFIG_CGROUPS, которую вы можете проверить с помощью:
cat /boot/config-$(uname -r) | grep -i cgroups
Если опция включена, вы должны увидеть:
CONFIG_CGROUPS=y
Используя cgroups, вы можете управлять объемом разрешенного использования ресурсов для каждого процесса, как описано в главах с 1 по 4 руководства по управлению ресурсами Red Hat Enterprise Linux 7, в главе 9 документа openSUSE System Analysis. и руководство по настройке, а также в разделе «Группы управления» документации сервера Ubuntu 14.04.
/proc/2822/fd — это каталог, который содержит одну символическую ссылку для каждого файлового дескриптора, открытого процессом. На следующем изображении показана информация о процессе, запущенном в tty1 (первом терминале) для создания образа .iso:
На изображении выше показано, что stdin (дескриптор файла 0), stdout (дескриптор файла 1) и stderr (дескриптор файла 2) сопоставляются с /dev/zero, /root/test.iso и . >/dev/tty1 соответственно.
Дополнительную информацию о /proc можно найти в документе «Файловая система /proc», который хранится и поддерживается Kernel.org, а также в Руководстве программиста Linux.
Установка ограничений ресурсов для каждого пользователя в Linux
Если вы не будете осторожны и позволите любому пользователю запускать неограниченное количество процессов, вы можете в конечном итоге столкнуться с неожиданным завершением работы системы или ее блокировкой, поскольку система перейдет в непригодное для использования состояние. Чтобы этого не произошло, следует установить ограничение на количество процессов, которые могут запускать пользователи.
Для этого отредактируйте /etc/security/limits.conf и добавьте следующую строку внизу файла, чтобы установить ограничение:
* hard nproc 10
Первое поле может использоваться для указания пользователя, группы или всех из них (*), тогда как второе поле устанавливает жесткое ограничение на количество процессов (nproc) до 10. Чтобы применить изменения, достаточно выйти и снова войти.
Итак, давайте посмотрим, что произойдет, если определенный пользователь, отличный от root (легитимный или нет), попытается запустить бомбу-вилку оболочки. Если бы мы не реализовали ограничения, сначала было бы запущено два экземпляра функции, а затем каждый из них дублировался бы в бесконечном цикле. Таким образом, в конечном итоге это приведет к сканированию вашей системы.
Однако при наличии вышеуказанного ограничения форк-бомба не увенчается успехом, но пользователь все равно будет заблокирован, пока системный администратор не уничтожит связанный с ним процесс:
СОВЕТ: Другие возможные ограничения, которые возможны с помощью ulimit, описаны в файле limits.conf.
Другие инструменты управления процессами Linux
В дополнение к инструментам, обсуждавшимся ранее, системному администратору также может потребоваться:
a) Измените приоритет выполнения (использование системных ресурсов) процесса с помощью renice. Это означает, что ядро будет выделять процессу больше или меньше системных ресурсов в зависимости от назначенного приоритета (число, обычно известное как «приятность» в диапазоне от -20 до 19).
Чем ниже значение, тем выше приоритет выполнения. Обычные пользователи (кроме root) могут изменять качество принадлежащих им процессов только на более высокое значение (что означает более низкий приоритет выполнения), тогда как root может изменять это значение для любого процесса и может увеличивать или уменьшать его.
Основной синтаксис renice следующий:
renice [-n] <new priority> <UID, GID, PGID, or empty> identifier
Если аргумент после нового значения приоритета отсутствует (пустой), по умолчанию ему присваивается значение PID. В этом случае качество процесса с PID=identifier устанавливается на
b) Прерывать нормальное выполнение процесса, когда это необходимо. Это широко известно как «убийство» процесса. На самом деле это означает отправку процессу сигнала о правильном завершении его выполнения и упорядоченном освобождении всех используемых ресурсов.
Чтобы завершить процесс, используйте команду kill следующим образом:
kill PID
Альтернативно, вы можете использовать pkill для завершения всех процессов данного владельца (-u) или владельца группы (-G) или даже тех процессов, которые имеют PPID обычно (-P). За этими опциями может следовать числовое представление или фактическое имя в качестве идентификатора:
pkill [options] identifier
Например,
pkill -G 1000
уничтожит все процессы, принадлежащие группе с GID=1000.
И,
pkill -P 4993
уничтожит все процессы, PPID которых равен 4993.
Прежде чем запускать pkill, рекомендуется сначала проверить результаты с помощью pgrep, возможно, также используя параметр -l, чтобы получить список имена процессов. Он принимает те же параметры, но возвращает только PID процессов (без каких-либо дополнительных действий), которые будут уничтожены при использовании pkill.
pgrep -l -u gacanepa
Это показано на следующем изображении:
Краткое содержание
В этой статье мы рассмотрели несколько способов мониторинга использования ресурсов, чтобы проверить целостность и доступность критически важных аппаратных и программных компонентов в системе Linux.
Мы также научились предпринимать соответствующие действия (либо корректируя приоритет выполнения данного процесса, либо завершая его) в необычных обстоятельствах.
Мы надеемся, что концепции, изложенные в этом руководстве, оказались полезными. Если у вас есть какие-либо вопросы или комментарии, свяжитесь с нами, используя контактную форму ниже.