Compare commits
2 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
5fb4692385 | ||
|
|
a0a5e1f4ac |
439
s4a.tex
439
s4a.tex
@@ -3680,14 +3680,451 @@ $ journalctl /dev/sdc
|
||||
$ journalctl /usr/sbin/vpnc
|
||||
\end{Verbatim}
|
||||
Хм, ничего подозрительного. Но, кажется, проблема где-то во взаимодействии между
|
||||
+vpnc+ и +dhclient+. Посмотрим объединенный и отсортированный по времени списов
|
||||
+vpnc+ и +dhclient+. Посмотрим объединенный и отсортированный по времени список
|
||||
сообщений от этих процессов:
|
||||
\begin{Verbatim}
|
||||
$ journalctl /usr/sbin/vpnc /usr/sbin/dhclient
|
||||
\end{Verbatim}
|
||||
Отлично, мы нашли причину проблемы!
|
||||
|
||||
\subsection{Продвинутые методы выборки}
|
||||
|
||||
Да, это все, конечно, здорово, но попробуем подняться еще на ступеньку выше.
|
||||
Чтобы понять описанные ниже приемы, нужно знать, что systemd добавляет к
|
||||
каждой лог-записи ряд скрытых метаданных. Эти метаданные по структуре напоминают
|
||||
набор переменных окружения, хотя на самом деле дают даже больше возможностей:
|
||||
во-первых, метаданные могут включать большие бинарные блоки данных (впрочем, это
|
||||
скорее исключение~--- обычно они содержат текст в кодировке UTF-8), и во-вторых,
|
||||
в пределах одной записи поле метаданных может содержать сразу несколько
|
||||
значений (и это тоже встречается нечасто~--- обычно поля содержат по одному
|
||||
значению). Эти метаданные автоматически собираются и добавляются для каждой
|
||||
лог-записи, безо всякого участия пользователя. И вы легко можете их использовать
|
||||
для более тонкой выборки записей. Посмотрим, как они выглядят:
|
||||
\begin{Verbatim}
|
||||
$ journalctl -o verbose -n1
|
||||
Tue, 2012-10-23 23:51:38 CEST [s=ac9e9c423355411d87bf0ba1a9b424e8;i=4301;b=5335e9cf5d954633bb99aefc0ec38c25;m=882ee28d2;t=4ccc0f98326e6;x=f21e8b1b0994d7ee]
|
||||
PRIORITY=6
|
||||
SYSLOG_FACILITY=3
|
||||
_MACHINE_ID=a91663387a90b89f185d4e860000001a
|
||||
_HOSTNAME=epsilon
|
||||
_TRANSPORT=syslog
|
||||
SYSLOG_IDENTIFIER=avahi-daemon
|
||||
_COMM=avahi-daemon
|
||||
_EXE=/usr/sbin/avahi-daemon
|
||||
_SYSTEMD_CGROUP=/system/avahi-daemon.service
|
||||
_SYSTEMD_UNIT=avahi-daemon.service
|
||||
_SELINUX_CONTEXT=system_u:system_r:avahi_t:s0
|
||||
_UID=70
|
||||
_GID=70
|
||||
_CMDLINE=avahi-daemon: registering [epsilon.local]
|
||||
MESSAGE=Joining mDNS multicast group on interface wlan0.IPv4 with address 172.31.0.53.
|
||||
_BOOT_ID=5335e9cf5d954633bb99aefc0ec38c25
|
||||
_PID=27937
|
||||
SYSLOG_PID=27937
|
||||
_SOURCE_REALTIME_TIMESTAMP=1351029098747042
|
||||
\end{Verbatim}
|
||||
(Чтобы не~утомлять вас огромным количеством текста, ограничимся одной записью.
|
||||
Ключ +-n+ позволяет задать число выводимых записей, в нашем случае 1. Если
|
||||
указать его без параметра, будут показаны 10 последних записей.)
|
||||
|
||||
Задав параметр +-o verbose+, мы переключили формат вывода~--- теперь, вместо
|
||||
скупых строчек, копирующих +/var/log/messages+, для каждой записи выводится
|
||||
полный перечень всех метаданных. В том числе, информация о пользователе и
|
||||
группе, контекст SELinux, идентификатор компьютера и т.д. Полный список
|
||||
общеизвестных полей метаданных приведен на соответствующей
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html}%
|
||||
{странице руководства}.
|
||||
|
||||
И база данных Journal индексируется по \emph{всем} этим полям! И мы можем
|
||||
использовать любое из них в качестве критерия выборки:
|
||||
\begin{Verbatim}
|
||||
$ journalctl _UID=70
|
||||
\end{Verbatim}
|
||||
Как нетрудно догадаться, в результате будут выведены все сообщения от
|
||||
процессов пользователя с UID 70. При необходимости, критерии можно
|
||||
комбинировать:
|
||||
\begin{Verbatim}
|
||||
$ journalctl _UID=70 _UID=71
|
||||
\end{Verbatim}
|
||||
Указание двух значений для одного и того же поля эквивалентно логическому ИЛИ.
|
||||
Таким образом, будут выведены записи как от процессов с UID 70, так и от
|
||||
процессов с UID 71.
|
||||
\begin{Verbatim}
|
||||
$ journalctl _HOSTNAME=epsilon _COMM=avahi-daemon
|
||||
\end{Verbatim}
|
||||
А указание двух \emph{различных} полей дает эффект логического И. В результате,
|
||||
будут выведены записи только от процесса +avahi-daemon+, работающего на хосте с
|
||||
именем +epsilon+.
|
||||
|
||||
Но мы этим не~ограничимся! Мы же суровые компьютерщики, мы хотим использовать
|
||||
сложные логические выражения!
|
||||
\begin{Verbatim}
|
||||
$ journalctl _HOSTNAME=theta _UID=70 + _HOSTNAME=epsilon _COMM=avahi-daemon
|
||||
\end{Verbatim}
|
||||
При помощи плюса мы можем явно задать логическое ИЛИ, применяя его к разным
|
||||
полям и даже И-выражениям. Поэтому наш пример выведет как записи с хоста
|
||||
+theta+ от процессов с UID 70, так и с хоста +epsilon+ от процесса
|
||||
+avahi-daemon+\footnote{Прим. перев.: Стоит отметить, что приоритет логических
|
||||
операций стандартный: сначала выполняются операции И, и только потом~---
|
||||
операции ИЛИ. Используемая в +journalctl+ система записи выражений аналогична
|
||||
принятой в классической алгебре: умножение (имеющее более высокий приоритет)
|
||||
не~указывается знаком операции, а обозначается просто последовательной
|
||||
записью величин.}.
|
||||
|
||||
\subsection{И немного магии}
|
||||
|
||||
Уже неплохо, правда? Но есть один недостаток~--- мы же не~сможем запомнить все
|
||||
возможные значения все полей журнала! Для этого была бы нужна очень хорошая
|
||||
память. Но +journalctl+ вновь приходит к нам на помощь:
|
||||
\begin{Verbatim}
|
||||
$ journalctl -F _SYSTEMD_UNIT
|
||||
\end{Verbatim}
|
||||
Эта команда выведет все значения поля +_SYSTEMD_UNIT+, зарегистрированные в базе
|
||||
данных журнала на текущий момент. То есть, имена всех юнитов +systemd+, которые
|
||||
писали что-либо в журнал. Аналогичный запрос работает для всех полей, так что
|
||||
найти точное значение для выборки по нему~--- уже не~проблема. Но тут самое
|
||||
время сообщить вам, что эта функциональность встроена в механизм автодополнения
|
||||
оболочки\footnote{Прим. перев.: В исходной статье речь идет только о bash,
|
||||
однако, начиная с релиза systemd 196, аналогичная функциональность доступна и
|
||||
для zsh.}! Это же просто прекрасно~--- вы можете просмотреть перечень значений
|
||||
поля и выбрать из него нужно прямо при вводе выражения. Возьмем для примера
|
||||
метки SELinux. Помнится, имя поле начиналось с букв SE\ldots{}
|
||||
\begin{Verbatim}[commandchars=\\\{\}]
|
||||
$ journalctl _SE\textbf{<TAB>}
|
||||
\end{Verbatim}
|
||||
и оболочка сразу же дополнит:
|
||||
\begin{Verbatim}
|
||||
$ journalctl _SELINUX_CONTEXT=
|
||||
\end{Verbatim}
|
||||
Отлично, и какое там значение нам нужно?
|
||||
\begin{Verbatim}[fontsize=\small]
|
||||
$ journalctl _SELINUX_CONTEXT=<TAB><TAB>
|
||||
kernel system_u:system_r:rtkit_daemon_t:s0
|
||||
system_u:system_r:accountsd_t:s0 system_u:system_r:syslogd_t:s0
|
||||
system_u:system_r:avahi_t:s0 system_u:system_r:system_cronjob_t:s0-s0:c0.c1023
|
||||
system_u:system_r:bluetooth_t:s0 system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
|
||||
system_u:system_r:chkpwd_t:s0-s0:c0.c1023 system_u:system_r:systemd_logind_t:s0
|
||||
system_u:system_r:chronyd_t:s0 system_u:system_r:systemd_tmpfiles_t:s0
|
||||
system_u:system_r:crond_t:s0-s0:c0.c1023 system_u:system_r:udev_t:s0-s0:c0.c1023
|
||||
system_u:system_r:devicekit_disk_t:s0 system_u:system_r:virtd_t:s0-s0:c0.c1023 c0.c1023
|
||||
system_u:system_r:dhcpc_t:s0 system_u:system_r:vpnc_t:s0 sd_t:s0-s0:c0.c1023
|
||||
system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 system_u:system_r:xdm_t:s0-s0:c0.c1023
|
||||
system_u:system_r:init_t:s0 unconfined_u:system_r:rpm_t:s0-s0:c0.c1023
|
||||
system_u:system_r:local_login_t:s0-s0:c0.c1023 unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023
|
||||
system_u:system_r:lvm_t:s0 unconfined_u:system_r:useradd_t:s0-s0:c0.c1023
|
||||
system_u:system_r:modemmanager_t:s0-s0:c0.c1023 unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023
|
||||
system_u:system_r:NetworkManager_t:s0 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
|
||||
system_u:system_r:policykit_t:s0
|
||||
\end{Verbatim}
|
||||
Ага, нас интересуют записи с меткой PolicyKit! Пользуясь дополнением, вводим:
|
||||
\begin{Verbatim}
|
||||
$ journalctl _SELINUX_CONTEXT=system_u:system_r:policykit_t:s0
|
||||
\end{Verbatim}
|
||||
Очень просто, не~правда ли! Пожалуй, самое простое из действий, связанных с
|
||||
SELinux ;-) Разумеется, такое дополнение работает для всех полей Journal.
|
||||
|
||||
На сегодня все. Впрочем, на странице руководства
|
||||
\href{http://www.freedesktop.org/software/systemd/man/journalctl.html}%
|
||||
{journalctl(1)} можно узнать и о многих других возможностях, не~описанных здесь.
|
||||
Например, о том, что +journalctl+ может выводить данные в формате JSON, или в
|
||||
формате +/var/log/messages+, но с относительными метками времени, как в dmesg.
|
||||
|
||||
\section{Управление ресурсами с помощью cgroups}
|
||||
|
||||
Важную роль в современных компьютерных системах играют механизмы управления
|
||||
использованием ресурсов: когда вы запускаете на одной системе несколько
|
||||
программ, возникает необходимость распределять между ними ресурсы системы,
|
||||
в соответствии с некоторыми правилами. В частности, это особенно актуально на
|
||||
маломощных встраиваемых и мобильных системах, обладающих очень скудными
|
||||
ресурсами. Но та же задача актуальна и для очень мощных вычислительных
|
||||
кластеров, которые располагают огромными ресурсами, но при это несут и огромную
|
||||
вычислительную нагрузку.
|
||||
|
||||
Исторически, в Linux поддерживался только одна схема управления ресурсами: все
|
||||
процессы получают примерно равные доли процессорного времени или потока
|
||||
ввода-вывода. При необходимости соотношение этих долей можно изменить при
|
||||
помощи значения \emph{nice}, задаваемого для каждого процесса. Такой подход
|
||||
очень прост, и на протяжении долгих лет покрывал все нужды пользователей Linux.
|
||||
Но у него есть существенный недостаток: он оперирует лишь отдельными процессами,
|
||||
но не~их группами. В результате, например, веб-сервер Apache с множеством
|
||||
CGI-процессов при прочих равных получает гораздо больше ресурсов, чем служба
|
||||
syslog, у которой не~так много процессов.
|
||||
|
||||
В процессе проектирования архитектуры systemd, мы практически сразу поняли, что
|
||||
управление ресурсов должно быть одной из его базовых функций, заложенных в
|
||||
основы его структуры. В современной системе~--- неважно, серверной или
|
||||
встраиваемой~--- контроль использования процессора, памяти и ввода-вывода для
|
||||
различных служб нельзя добавлять задним числом. Такая функциональность должна
|
||||
быть доступна изначально, через базовые настройки запуска служб. При этом,
|
||||
ресурсы должны распределяться на уровне служб, а не~процессов, как это делалось
|
||||
при помощи значений nice или \href{http://linux.die.net/man/2/setrlimit}{POSIX
|
||||
Resource Limits}.
|
||||
|
||||
В этой статье я попробую рассказать о методах управления механизмами
|
||||
распределения ресурсов между службами systemd. Эта функциональность присутствует
|
||||
в systemd уже долгое время, и давно пора рассказать о ней пользователям и
|
||||
администраторам.
|
||||
|
||||
В свое время я
|
||||
\href{http://0pointer.de/blog/projects/cgroups-vs-cgroups.html}{пояснял}%
|
||||
\footnote{Прим. перев.: В указанном документе автор рассказывает, что
|
||||
контрольные группы Linux состоят из двух сущностей: \textbf{(A)} механизма
|
||||
иерархической группировки и маркировки процессов, и \textbf{(B)} механизма,
|
||||
позволяющего распределять ресурсы между полученными группами. Для работы (B)
|
||||
необходимо (A), но не~наоборот~--- (A) может прекрасно работать без (B). Для
|
||||
нормально функционирования systemd (A) \emph{необходим}, а (B) опционален (он
|
||||
лишь обеспечивает работу некоторых настроек). Вы можете собрать ядро только с
|
||||
необходимой для (A) опцией +CONFIG_CGROUPS=y+, отключив все связанные с (B)
|
||||
опции (такие как {\tiny +CONFIG_CGROUP_FREEZER=y+, +CONFIG_CGROUP_DEVICE=y+,
|
||||
+CONFIG_CGROUP_CPUACCT=y+, +CONFIG_CGROUP_MEM_RES_CTLR=y+,
|
||||
+CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y+, +CONFIG_CGROUP_MEM_RES_CTLR_KMEM=y+,
|
||||
+CONFIG_CGROUP_PERF=y+, +CONFIG_CGROUP_SCHED=y+, +CONFIG_BLK_CGROUP=y+,
|
||||
+CONFIG_NET_CLS_CGROUP=y+, +CONFIG_NET_PRIO_CGROUP=y+}), и systemd будет
|
||||
нормально работать на такой системе (за исключением того, что связанные с этими
|
||||
контроллерами настройки не~будут срабатывать). Однако, если собрать ядро без
|
||||
+CONFIG_CGROUPS=y+, функциональность systemd будет сильно ограничена. При этом,
|
||||
автор особо подчеркивает, что все негативные эффекты влияния контрольных групп
|
||||
на производительность обусловлены именно (B), в то время как (A) на
|
||||
производительность практически не~влияет.}, что контрольные группы Linux
|
||||
(cgroups) могут работать и как механизм группировки и отслеживания процессов, и
|
||||
как инструмент управления использованием ресурсов. Для функционирования systemd
|
||||
необходим только первый из этих режимов, а второй опционален. И именно этот
|
||||
опциональный второй режим дает вам возможность распределять ресурсы между
|
||||
службами. (А сейчас очень рекомендую вам, прежде чем продолжать чтение этой
|
||||
статьи, ознакомиться с \href{https://en.wikipedia.org/wiki/Cgroups}{базовой
|
||||
информацией о cgroups}. Хотя дальнейшие рассуждения и не~будут затрагивать
|
||||
низкоуровневые аспекты, все же будет лучше, если у вас сформируется некоторое
|
||||
представление о них.)
|
||||
|
||||
Основными контроллерами cgroups, отвечающими за управление ресурсами, являются
|
||||
\href{http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt}{cpu},
|
||||
\href{http://www.kernel.org/doc/Documentation/cgroups/memory.txt}{memory} и
|
||||
\href{http://www.kernel.org/doc/Documentation/cgroups/blkio-controller.txt}{blkio}.
|
||||
Для их использования необходимо, чтобы они были включены на этапе сборки ядра;
|
||||
большинство дистрибутивов (в том числе и Fedora), включают их в штатных ядрах.
|
||||
systemd предоставляет ряд высокоуровневых настроек, позволяющих использовать эти
|
||||
контроллеры, не~вникая в технические детали их работы.
|
||||
|
||||
\subsection{Процессор}
|
||||
|
||||
Если в ядре включен контроллер +cpu+, systemd по умолчанию создает контрольную
|
||||
группу по этому ресурсу для каждой службы. Даже без каких-либо дополнительных
|
||||
настроек это дает положительных эффект: на системе под управлением systemd все
|
||||
службы получают равные доли процессорного времени, независимо от количества
|
||||
процессов, запущенных в рамках службы. Например, на вашем веб-сервере MySQL с
|
||||
несколькими рабочими процессами получит такую же долю процессорного времени,
|
||||
как и Apache, даже если тот запустил 1000 CGI-процессов. Разумеется, такое
|
||||
поведение при необходимости можно легко отключить~--- см. опцию
|
||||
\href{http://0pointer.de/public/systemd-man/systemd.conf.html}{DefaultControllers=}
|
||||
в файле +/etc/systemd/system.conf+.
|
||||
|
||||
Если \emph{равномерное} распределение процессорного времени между службами вас
|
||||
не~устраивает, и вы хотите выделить определенным службам больше или меньше
|
||||
времени~--- используйте опцию
|
||||
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{CPUShares} в
|
||||
конфигурационном файле службы. По умолчанию это значение равно 1024. Увеличивая
|
||||
это число, вы даете службе больше процессорного времени, уменьшая~---
|
||||
соответственно, меньше.
|
||||
|
||||
Рассмотрим небольшой практический пример. Допустим, вам нужно увеличить
|
||||
для службы Apache относительную долю потребления процессора до 1500. Для этого
|
||||
создаем файл <<ручных>> настроек +/etc/systemd/system/httpd.service+, который
|
||||
включает в себя все те же опции, что и файл настроек по умолчанию
|
||||
+/usr/lib/systemd/system/httpd.service+, отличаясь от него только значением
|
||||
+CPUShares=+:
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
[Service]
|
||||
CPUShares=1500
|
||||
\end{Verbatim}
|
||||
Первая строка обеспечивает включение в нашу конфигурацию файла с настройками по
|
||||
умолчанию, сделанными разработчиками Apache или его сопровождающими в вашем
|
||||
дистрибутиве (если это включение не~указать явно, данный файл будет проигнорирован).
|
||||
Далее, мы указываем тот параметр, который хотим изменить. Сохраняем файл,
|
||||
приказываем systemd перечитать конфигурацию, и перезапускаем Apache, чтобы
|
||||
настройки вступили в силу\footnote{Прим. перев.: К сожалению, в настоящее время
|
||||
systemd не~поддерживает изменение параметров контрольных групп без перезапуска
|
||||
службы. Но вы можете узнать контрольную группу службы командой наподобие
|
||||
+systemctl show -p ControlGroup avahi-daemon.service+, и выполнить настройки
|
||||
любым удобным для вас способом, например, через запись значений в псевдофайлы
|
||||
cgroupfs. Разумеется, при следующем запуске службы к ней будут применены
|
||||
параметры, указанные в конфигурационном файле.}:
|
||||
\begin{Verbatim}
|
||||
systemctl daemon-reload
|
||||
systemctl restart httpd.service
|
||||
\end{Verbatim}
|
||||
Готово!
|
||||
|
||||
Обратите внимание, что явное указание значения +CPUShares=+ в конфигурации
|
||||
службы заставит systemd создать для нее контрольную группу в иерархии контроллера
|
||||
+cpu+, даже если этот контроллер не~указан в +DefaultControllers=+ (см. выше).
|
||||
|
||||
\subsection{Отслеживание использования ресурсов}
|
||||
|
||||
Для того, чтобы правильно распределять ресурсы между службами, неплохо бы знать
|
||||
реальные потребности этих служб. Чтобы упростить для вас отслеживание
|
||||
потребления ресурсов службами, мы подготовили утилиту
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd-cgtop.html}{systemd-cgtop},
|
||||
которая находит все имеющиеся в системе контрольные группы, определяет для
|
||||
каждой из них количество потребляемых ресурсов (процессорное время, память и
|
||||
ввод-вывод) и выводит эти данные в динамически обновляемой сводной таблице, по аналогии
|
||||
с программой \href{http://linux.die.net/man/1/top}{top}. Используя вводимое
|
||||
systemd распределение служб по контрольным группам, эта утилита выводит для
|
||||
служб те же сведения, которые top выводит для отдельных процессов.
|
||||
|
||||
К сожалению, по умолчанию +cgtop+ может раздельно отслеживать для каждой службы
|
||||
только потребление процессорного времени, а сведения по использованию памяти и
|
||||
ввода-вывода доступны только для всей системы в целом. Это ограничение возникает
|
||||
из-за того, что в конфигурации по умолчанию контрольные группы для служб
|
||||
создаются только в иерархии контроллера +cpu+, но не~+memory+ и~+blkio+. Без
|
||||
создания групп в иерархии этих контроллеров невозможно отследить использование
|
||||
ресурса по службам. Самый простой способ обойти это ограничение~--- приказать
|
||||
systemd создавать соответствующие группы, добавив +memory+ и +blkio+ в перечень
|
||||
+DefaultControllers=+ в файле +system.conf+.
|
||||
|
||||
\subsection{Память}
|
||||
|
||||
Используя опции +MemoryLimit=+ и +MemorySoftLimit=+, вы можете ограничивать
|
||||
суммарное потребление оперативной памяти всеми процессами службы. В них
|
||||
указывается предел потребления памяти в байтах\footnote{Прим. перев.: Разница
|
||||
между +MemorySoftLimit=+ и +MemoryLimit=+ состоит в том, что первый предел можно
|
||||
превышать, если в системе еще есть достаточное количество свободной памяти.
|
||||
Второй из этих пределов превышать нельзя, независимо от наличия свободной
|
||||
памяти. Подробнее см. раздел <<Soft limits>> в
|
||||
\href{http://www.kernel.org/doc/Documentation/cgroups/memory.txt}{файле
|
||||
документации}.}. При этом поддерживаются суффиксы K, M, G и T, обозначающие
|
||||
соответственно, килобайт, мегабайт, гигабайт и терабайт (по основанию 1024).
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
[Service]
|
||||
MemoryLimit=1G
|
||||
\end{Verbatim}
|
||||
|
||||
По аналогии с +CPUShares=+, явное указание этих опций заставит systemd создать
|
||||
для службы контрольную группу в иерархии контроллера +memory+, даже если он
|
||||
не~был указан в +DefaultControllers=+.
|
||||
|
||||
\subsection{Ввод-вывод}
|
||||
|
||||
Для контроля пропускной полосы ввода-вывода с блочных устройств, доступно
|
||||
несколько настроек. Первая из них~--- +BlockIOWeight=+, задающая \emph{долю} полосы
|
||||
ввода-вывода для указанной службы. Принцип похож на +CPUShares=+ (см. выше), однако
|
||||
здесь величина относительной доли ограничена значениями от 10 до 1000. По
|
||||
умолчанию, она равна 1000. Уменьшить долю для службы Apache можно так:
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
[Service]
|
||||
BlockIOWeight=500
|
||||
\end{Verbatim}
|
||||
|
||||
При необходимости, вы можете задать это значение отдельно для каждого
|
||||
устройства:
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
[Service]
|
||||
BlockIOWeight=/dev/disk/by-id/ata-SAMSUNG_MMCRE28G8MXP-0VBL1_DC06K01009SE009B5252 750
|
||||
\end{Verbatim}
|
||||
|
||||
При этом, точное название устройства знать не~обязательно~--- достаточно указать
|
||||
интересующий вас каталог:
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
[Service]
|
||||
BlockIOWeight=/home/lennart 750
|
||||
\end{Verbatim}
|
||||
Если заданный вами путь не~указывает на файл устройства, systemd автоматически
|
||||
определит, на каком устройстве расположен указанный файл/каталог, и выставит для
|
||||
этого устройства соответствующую настройку.
|
||||
|
||||
Вы можете добавить несколько таких строк, задавая долю пропускной полосы
|
||||
отдельно для различных устройств, и при этом также допускается указать <<общее>>
|
||||
значение (как в первом примере), которое будет использовано для всех остальных
|
||||
устройств.
|
||||
|
||||
В качестве альтернативы относительной доле пропускной полосы, вы также можете
|
||||
ограничивать абсолютную долю, используя настройки +BlockIOReadBandwidth=+ и
|
||||
+BlockIOWriteBandwidth=+. В них нужно указать устройство или любой находящийся
|
||||
на нем файл/каталог, а также предельную скорость чтения/записи в байтах в
|
||||
секунду:
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
[Service]
|
||||
BlockIOReadBandwith=/var/log 5M
|
||||
\end{Verbatim}
|
||||
В результате, для данной службы скорость чтения с устройства, содержащего
|
||||
каталог +/var/log+, будет ограничена величиной 5 мегабайт в секунду.
|
||||
|
||||
По аналогии с вышеописанными +CPUShares=+ и +MemoryLimit=+, явное указание любой
|
||||
из приведенных настроек пропускной полосы заставит systemd создать для службы
|
||||
контрольную группу в иерархии контроллера +blkio+.
|
||||
|
||||
\subsection{Прочие параметры}
|
||||
|
||||
Вышеописанные опции покрывают лишь малую толику настроек, поддерживаемых
|
||||
различными контроллерами Linux croups. Мы добавили высокоуровневый интерфейс
|
||||
только к тем настройкам, которые кажутся нам наиболее важным для большинства
|
||||
пользователей. Из соображений удобства мы добавили механизмы, обеспечивающие
|
||||
поддержку крупных единиц измерения (килобайты, мегабайты и т.д.) и
|
||||
автоматическое определение блочных устройств по указанному файлу/каталогу.
|
||||
|
||||
В некоторых случаях описанных высокоуровневых настроек может оказаться
|
||||
недостаточно~--- допустим, вам нужно задать низкоуровневую настройку cgroups,
|
||||
для которой мы (пока) не~добавили высокоуровневого аналога. На этот случай мы
|
||||
предусмотрели универсальных механизм задания таких опций в конфигурационных
|
||||
файлах юнитов. Рассмотрим, например, задание для службы параметра
|
||||
\emph{swappiness} (относительная интенсивность использования подкачки для
|
||||
процессов службы). В systemd нет высокоуровневой настройки для этого значения.
|
||||
Однако вы можете задать его, используя низкоуровневую настройку
|
||||
+ControlGroupAttribute=+:
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
[Service]
|
||||
ControlGroupAttribute=memory.swappiness 70
|
||||
\end{Verbatim}
|
||||
Как обычно, явное указание настройки, относящейся к какому-либо контроллеру (в
|
||||
нашем случае +memory+) приведет к автоматическому созданию группы в иерархии
|
||||
данного контроллера.
|
||||
|
||||
В дальнейшем, возможно, мы расширим возможности высокоуровневой настройки
|
||||
различных параметров контрольных групп. Если вы часто пользуетесь какими-то из
|
||||
них и полагаете, что для них можно добавить соответствующие опции~---
|
||||
не~стесняйтесь обращаться к нам. А лучше всего~--- присылайте сразу патч!
|
||||
|
||||
\begin{caveat}
|
||||
Обратите внимание, что использование некоторых контроллеров может сильно
|
||||
сказаться на производительности системы. Это та цена, которую приходится
|
||||
платить за контроль над ресурсами. Использование таких контроллеров
|
||||
может ощутимо замедлить некоторые операции. В частности, весьма
|
||||
нелестная в этом плане репутация закрепилась за контроллером +memory+
|
||||
(хотя, не~исключено, что эта проблема уже исправлена в свежих выпусках
|
||||
ядра).
|
||||
\end{caveat}
|
||||
|
||||
Для углубленного изучения темы, затронутой в этой статье, вы можете обратиться к
|
||||
документации по
|
||||
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{поддерживаемым
|
||||
настройкам юнитов}, а также по контроллерам
|
||||
\href{http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt}{cpu},
|
||||
\href{http://www.kernel.org/doc/Documentation/cgroups/memory.txt}{memory} и
|
||||
\href{http://www.kernel.org/doc/Documentation/cgroups/blkio-controller.txt}{blkio}.
|
||||
|
||||
Стоит подчеркнуть, что мы сейчас обсуждали распределение ресурсов \emph{между
|
||||
службами}. В дополнение к этим современным механизмам, systemd также
|
||||
поддерживает и традиционные настройки, касающиеся распределения ресурсов
|
||||
\emph{между отдельными процессами}. Хотя такие настройки обычно наследуются
|
||||
порожденными процессами, они, тем не~менее, все равно ограничивают ресурсы
|
||||
на уровне отдельных процессов. В частности, к ним относятся +IOSchedulingClass=+,
|
||||
+IOSchedulingPriority=+, +CPUSchedulingPolicy=+, +CPUSchedulingPriority=+,
|
||||
+CPUAffinity=+, +LimitCPU=+ и т.п. Для их работы не~требуют контроллеры cgroups,
|
||||
и они не~так сильно ухудшают производительность. Возможно, мы рассмотрим их в
|
||||
последующих статьях.
|
||||
|
||||
\end{document}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user