Version v13.3 (2012-12-04 21:06) [AUTO]

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}