Частью работы системного администратора является анализ производительности систем, а также поиск и устранение проблем, которые вызывают низкую производительность и длительное время запуска. Системным администраторам также необходимо проверить другие аспекты конфигурации и использования systemd.
Система инициализации systemd предоставляет systemd-analyzeинструмент, который может помочь обнаружить проблемы с производительностью и другую важную информацию о systemd. В предыдущей статье « Анализ системного календаря иsystemd-analyze временных интервалов» я использовал для анализа временных меток и временных интервалов в системных таймерах, но у этого инструмента есть много других применений, некоторые из которых я рассмотрю в этой статье.
systemd-analyze
Последовательность запуска Linux — хорошее место для начала изучения, поскольку многие systemd-analyzeфункции инструмента предназначены для запуска. Но сначала важно понять разницу между загрузкой и запуском. Последовательность загрузки начинается с самотестирования BIOS при включении питания (POST) и заканчивается, когда ядро завершает загрузку и берет на себя управление хост-системой, что является началом запуска и моментом начала журнала systemd.
Результаты, которые я покажу ниже, получены с моей основной рабочей станции, что гораздо интереснее, чем результаты виртуальной машины. Эта рабочая станция состоит из материнской платы ASUS TUF X299 Mark 2, процессора Intel i9-7960X с 16 ядрами и 32 процессорами (потоков) и 64 ГБ оперативной памяти. Некоторые из приведенных ниже команд могут быть выполнены пользователем без полномочий root, но в этой статье я буду использовать root, чтобы не переключаться между пользователями.
Есть несколько вариантов проверки последовательности запуска. В простейшей форме systemd-analyzeкоманды отображается обзор количества времени, затраченного на каждый из основных разделов запуска, запуска, загрузки и запуска ядра initrd(т. Е. Начальный RAM-диск, временный образ системы, который используется для инициализации некоторого оборудования и монтирования /[корень] файловая система), и в пользовательском пространстве (где все программы и демоны должны принести хозяин до работоспособного состояния загружаются). Если команде не передана подкоманда, systemd-analyze timeподразумевается:
initrd
/
systemd-analyze time
[root@admins24 ~]$ systemd-analyze Startup finished in 53.921s (firmware) + 2.643s (loader) + 2.236s (kernel) + 4.348s (initrd) + 10.082s (userspace) = 1min 13.233s graphical.target reached after 10.071s in userspace [root@admins24 ~]#
Наиболее примечательными данными в этих выходных данных является количество времени, проведенное в прошивке (BIOS): почти 54 секунды. Это невероятное количество времени, и ни одна из других моих физических систем не занимает столько времени, чтобы пройти через BIOS.
Мой ноутбук System76 Oryx Pro проводит в BIOS всего 8,506 секунд, а все мои домашние системы — чуть меньше 10 секунд. После нескольких поисков в Интернете я обнаружил, что эта материнская плата известна чрезмерно долгим временем загрузки BIOS. Моя материнская плата никогда не «просто загружается». Он всегда зависает, и мне нужно выполнить цикл выключения / включения, а затем BIOS запускается с ошибкой, и мне нужно нажать F1, чтобы войти в конфигурацию BIOS, откуда я могу выбрать загрузочный диск и завершить загрузку. Вот откуда приходит дополнительное время.
Не все хосты показывают данные прошивки. Мои ненаучные эксперименты заставили меня поверить, что эти данные показаны только для процессоров Intel 9 поколения или выше. Но это могло быть неверно.
Этот обзор процесса загрузки при загрузке интересен и предоставляет хорошую (хотя и ограниченную) информацию, но о запуске доступно гораздо больше информации, о чем я расскажу ниже.
Вы можете использовать его, systemd-analyze blameчтобы узнать, какие модули systemd инициализируются больше всего. Результаты отображаются в порядке времени, необходимого для инициализации, от наибольшего к наименьшему:
systemd-analyze blame
[root@admins24 ~]$ systemd-analyze blame 5.417s NetworkManager-wait-online.service 3.423s dracut-initqueue.service 2.715s systemd-udev-settle.service 2.519s fstrim.service 1.275s udisks2.service 1.271s smartd.service 996ms upower.service 637ms lvm2-monitor.service 533ms lvm2-pvscan@8:17.service 520ms dmraid-activation.service 460ms vboxdrv.service 396ms initrd-switch-root.service <SNIP – removed lots of entries with increasingly small times>
Поскольку многие из этих сервисов запускаются параллельно, эти числа могут в сумме значительно превышать сумму, указанную systemd-analyze timeдля всего, что указано после BIOS. Все это небольшие цифры, поэтому я не могу найти здесь значительной экономии.
Данные этой команды могут дать представление о том, какие службы вы могли бы рассмотреть для улучшения времени загрузки. Неиспользуемые службы можно отключить. Похоже, что нет ни одной службы, которая занимала бы слишком много времени во время этой последовательности запуска. Вы можете увидеть разные результаты для каждой загрузки и запуска.
Как и критический путь в управлении проектами, критическая цепочка показывает критическую по времени цепочку событий, которые происходят во время запуска. Это модули systemd, на которые следует обратить внимание, если запуск происходит медленно, поскольку именно они могут вызывать задержки. Этот инструмент отображает не все запускаемые юниты, а только те, которые входят в эту критическую цепочку событий:
[root@admins24 ~]# systemd-analyze critical-chain The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. graphical.target @10.071s └─lxdm.service @10.071s └─plymouth-quit.service @10.047s +22ms └─systemd-user-sessions.service @10.031s +7ms └─remote-fs.target @10.026s └─remote-fs-pre.target @10.025s └─nfs-client.target @4.636s └─gssproxy.service @4.607s +28ms └─network.target @4.604s └─NetworkManager.service @4.383s +219ms └─dbus-broker.service @4.434s +136ms └─dbus.socket @4.369s └─sysinit.target @4.354s └─systemd-update-utmp.service @4.345s +9ms └─auditd.service @4.301s +42ms └─systemd-tmpfiles-setup.service @4.254s +42ms └─import-state.service @4.233s +19ms └─local-fs.target @4.229s └─Virtual.mount @4.019s +209ms └─systemd-fsck@dev-mapper-vg_admins2\x2dVirtual.service @3.742s +274ms └─local-fs-pre.target @3.726s └─lvm2-monitor.service @356ms +637ms └─dm-event.socket @319ms └─-.mount └─system.slice └─-.slice [root@admins24 ~]#
Цифры перед ними @показывают абсолютное количество секунд с момента запуска, когда блок становится активным. Цифры, которым предшествует, +показывают количество времени, необходимое для запуска устройства.
@
+
Иногда нужно определить текущее состояние системы. Команда systemd-analyze dumpвыгружает огромное количество данных о текущем состоянии системы. Он начинается со списка основных временных меток загрузки, списка каждого модуля systemd и полного описания состояния каждого:
systemd-analyze dump
[root@admins24 ~]# systemd-analyze dump Timestamp firmware: 1min 7.983523s Timestamp loader: 3.872325s Timestamp kernel: Wed 2020-08-26 12:33:35 EDT Timestamp initrd: Wed 2020-08-26 12:33:38 EDT Timestamp userspace: Wed 2020-08-26 12:33:42 EDT Timestamp finish: Wed 2020-08-26 16:33:56 EDT Timestamp security-start: Wed 2020-08-26 12:33:42 EDT Timestamp security-finish: Wed 2020-08-26 12:33:42 EDT Timestamp generators-start: Wed 2020-08-26 16:33:42 EDT Timestamp generators-finish: Wed 2020-08-26 16:33:43 EDT Timestamp units-load-start: Wed 2020-08-26 16:33:43 EDT Timestamp units-load-finish: Wed 2020-08-26 16:33:43 EDT Timestamp initrd-security-start: Wed 2020-08-26 12:33:38 EDT Timestamp initrd-security-finish: Wed 2020-08-26 12:33:38 EDT Timestamp initrd-generators-start: Wed 2020-08-26 12:33:38 EDT Timestamp initrd-generators-finish: Wed 2020-08-26 12:33:38 EDT Timestamp initrd-units-load-start: Wed 2020-08-26 12:33:38 EDT Timestamp initrd-units-load-finish: Wed 2020-08-26 12:33:38 EDT -> Unit system.slice: Description: System Slice Instance: n/a Unit Load State: loaded Unit Active State: active State Change Timestamp: Wed 2020-08-26 12:33:38 EDT Inactive Exit Timestamp: Wed 2020-08-26 12:33:38 EDT Active Enter Timestamp: Wed 2020-08-26 12:33:38 EDT Active Exit Timestamp: n/a Inactive Enter Timestamp: n/a May GC: no <SNIP – Deleted a bazillion lines of output>
На моей основной рабочей станции эта команда сгенерировала поток из 49 680 строк размером около 1,66 МБ. Эта команда очень быстрая, поэтому ждать результатов не нужно.
Мне нравится обилие деталей, обеспечиваемых различными подключенными устройствами, такими как хранилище. Каждый модуль systemd имеет раздел с подробностями, такими как режимы для различных времен выполнения, каталоги кешей и журналов, командная строка, используемая для запуска модуля, идентификатор процесса (PID), отметка времени начала, а также ограничения памяти и файлов.
Страница systemd-analyzeруководства для показывает systemd-analyze --user dumpпараметр, который предназначен для отображения информации о внутреннем состоянии диспетчера пользователей. У меня это не получается, и поиск в Интернете показывает, что с этим может быть проблема. В systemd --userэкземпляры используются для управления и контроля ресурсов иерархии процессов, принадлежащих каждому пользователю. Процессы для каждого пользователя являются частью контрольной группы, о которой я расскажу в следующей статье.
systemd-analyze --user dump
--user
Большинство заостренных начальников (PHB) и многие хорошие менеджеры считают, что красивые графики легче читать и понимать, чем текстовые данные о производительности системы, которые я обычно предпочитаю. Тем не менее, иногда даже мне нравится хороший график, и я systemd-analyzeпредоставляю возможность отображать данные загрузки / запуска в виде диаграммы векторной графики SVG .
Следующая команда создает файл векторной графики, который отображает события, происходящие во время загрузки и запуска. Создание этого файла займет всего несколько секунд:
[root@admins24 ~]# systemd-analyze plot > /tmp/bootup.svg
Эта команда создает SVG, который представляет собой текстовый файл, который определяет серию графических векторов, которые приложения, в том числе Image Viewer, Ristretto, Okular, Eye of Mate, LibreOffice Draw и другие, используют для создания графика. Эти приложения обрабатывают файлы SVG для создания изображения.
Я использовал LibreOffice Draw для визуализации графика. График огромен, и вам нужно значительно увеличить масштаб, чтобы разглядеть какие-либо детали. Вот небольшая его часть:
Последовательность загрузки находится слева от нуля (0) на шкале времени на графике, а последовательность загрузки — справа от нуля. Эта небольшая часть показывает ядро initrd, и initrd запущенные процессы .
Этот график сразу показывает, что и когда началось, сколько времени потребовалось для запуска и основные зависимости. Критический путь выделен красным.
Другая команда, которая генерирует графический вывод, — это systemd-analyze plot. Он генерирует текстовые описания графов зависимостей в формате DOT . Полученный поток данных затем передается через dotслужебную программу, которая является частью семейства программ, которые можно использовать для создания файлов векторной графики из различных типов данных. Эти файлы SVG также можно обрабатывать с помощью перечисленных выше инструментов.
systemd-analyze plot
dot
Сначала сгенерируйте файл. На моей основной рабочей станции это заняло почти девять минут:
[root@admins24 ~]# time systemd-analyze dot | dot -Tsvg > /tmp/test.svg Color legend: black = Requires dark blue = Requisite dark grey = Wants red = Conflicts green = After real 8m37.544s user 8m35.375s sys 0m0.070s [root@admins24 ~]#
Я не буду воспроизводить здесь результат, потому что полученный график в значительной степени спагетти. Но вы должны попробовать и посмотреть результат, чтобы понять, что я имею в виду.
Одна из наиболее интересных, но в некоторой степени общих возможностей, которую я обнаружил при чтении systemd-analyze(1)страницы руководства, — это conditionподкоманда. (Да, я читаю справочные страницы, и это удивительно, что я узнал таким образом!) Эту conditionподкоманду можно использовать для проверки условий и утверждений, которые могут использоваться в файлах модулей systemd.
systemd-analyze(1)
condition
Его также можно использовать в сценариях для оценки одного или нескольких условий — он возвращает ноль (0), если все выполняются, или единицу (1), если какое-либо условие не выполняется. В любом случае он также извергает текст о своих выводах.
Приведенный ниже пример из справочной страницы немного сложен. Он проверяет версию ядра от 4.0 до 5.1, что хост работает от сети переменного тока, что архитектура системы не является ARM, и что каталог /etc/os-releaseсуществует. Я добавил echo $?инструкцию для печати кода возврата.
/etc/os-release
echo $?
[root@admins24 ~]# systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \ 'ConditionKernelVersion = >=5.1' \ 'ConditionACPower=|false' \ 'ConditionArchitecture=|!arm' \ 'AssertPathExists=/etc/os-release' ; \ echo $? test.service: AssertPathExists=/etc/os-release succeeded. Asserts succeeded. test.service: ConditionArchitecture=|!arm succeeded. test.service: ConditionACPower=|false failed. test.service: ConditionKernelVersion=>=5.1 succeeded. test.service: ConditionKernelVersion=!<4.0 succeeded. Conditions succeeded. 0 [root@admins24 ~]#
Список условий и утверждений начинается примерно со строки 600 на systemd.unit(5)странице руководства .
systemd.unit(5)
Этот systemd-analyzeинструмент предоставляет способ отправки содержимого различных файлов конфигурации STDOUT, как показано здесь. Базовый каталог /etc/:
STDOUT
/etc/
[root@admins24 ~]# systemd-analyze cat-config systemd/system/display-manager.service # /etc/systemd/system/display-manager.service [Unit] Description=LXDM (Lightweight X11 Display Manager) #Documentation=man:lxdm(8) Conflicts=getty@tty1.service After=systemd-user-sessions.service getty@tty1.service plymouth-quit.service livesys-late.service #Conflicts=plymouth-quit.service [Service] ExecStart=/usr/sbin/lxdm Restart=always IgnoreSIGPIPE=no #BusName=org.freedesktop.lxdm [Install] Alias=display-manager.service [root@admins24 ~]#
Это слишком много набора текста, чтобы делать ничего, кроме стандартной catкоманды. Следующая команда мне кажется немного полезной. Он может искать файлы с указанным шаблоном в стандартных местоположениях systemd:
cat
[root@admins24 ~]# systemctl cat backup* # /etc/systemd/system/backup.timer # This timer unit runs the local backup program # Licensed under GPL V2 # [Unit] Description=Perform system backups Requires=backup.service [Timer] Unit=backup.service OnCalendar=*-*-* 00:15:30 [Install] WantedBy=timers.target # /etc/systemd/system/backup.service # This service unit runs the rsbu backup program # Licensed under GPL V2 # [Unit] Description=Backup services using rsbu Wants=backup.timer [Service] Type=oneshot Environment="HOME=/root" ExecStart=/usr/local/bin/rsbu -bvd1 ExecStart=/usr/local/bin/rsbu -buvd2 [Install] WantedBy=multi-user.target [root@admins24 ~]#
Обе эти команды предваряют содержимое каждого файла строкой комментария, содержащей полный путь и имя файла.
После создания нового файла модуля может быть полезно проверить его синтаксис. Это то, что verifyделает подкоманда. Он может перечислять неверно написанные директивы и вызывать отсутствующие служебные единицы:
verify
[root@admins24 ~]# systemd-analyze verify /etc/systemd/system/backup.service
Придерживаясь философии Unix / Linux, согласно которой «тишина — это золото», отсутствие выходных сообщений означает, что в отсканированном файле нет ошибок.
В securityпроверяет Подкоманду уровень безопасности указанных услуг. Он работает только с служебными модулями, но не с другими типами файлов модулей:
security
[root@admins24 ~]# systemd-analyze security display-manager NAME DESCRIPTION > ✗ PrivateNetwork= Service has access to the host's network > ✗ User=/DynamicUser= Service runs as root user > ✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP) Service may change UID/GID identities/capabilities > ✗ CapabilityBoundingSet=~CAP_SYS_ADMIN Service has administrator privileges > ✗ CapabilityBoundingSet=~CAP_SYS_PTRACE Service has ptrace() debugging abilities > ✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets > ✗ RestrictNamespaces=~CLONE_NEWUSER Service may create user namespaces > ✗ RestrictAddressFamilies=~… Service may allocate exotic sockets > ✗ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP) Service may change file ownership/access mode/capabilities unres> ✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service may override UNIX file/IPC permission checks > ✗ CapabilityBoundingSet=~CAP_NET_ADMIN Service has network configuration privileges > ✗ CapabilityBoundingSet=~CAP_SYS_MODULE Service may load kernel modules <SNIP> ✗ CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG Service may issue vhangup() > ✗ CapabilityBoundingSet=~CAP_WAKE_ALARM Service may program timers that wake up the system > ✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets > → Overall exposure level for backup.service: 9.6 UNSAFE ? lines 34-81/81 (END)
Да, смайлы — это часть вывода. Но, конечно же, многим сервисам для работы нужен практически полный доступ ко всему. Я запускал эту программу против нескольких служб, включая мою собственную службу резервного копирования; результаты могут отличаться, но итоги, кажется, в основном такие же.
Этот инструмент был бы очень полезен для проверки и исправления сервисных единиц пользовательского пространства в критических с точки зрения безопасности средах. Я не думаю, что он может многое предложить большинству из нас.
Этот мощный инструмент предлагает несколько интересных и удивительно полезных функций. Большая часть того, что исследуется в этой статье, касается использования systemd-analyzeдля получения представления о производительности Linux при запуске с использованием systemd. Он также может анализировать другие аспекты systemd.
Некоторые из этих инструментов имеют ограниченное применение, и о некоторых следует полностью забыть. Но большинство из них можно использовать с хорошими результатами при решении проблем с запуском и другими функциями systemd.
Продолжая использовать данный сайт вы принимаете политику конфиденциальности и cookies
