Version v5.3 (2011-05-21 18:35) [AUTO]

s4a.tex

@@ -1050,7 +1050,7 @@ systemd и на этот случай есть простое решение, и
 		Заметим, что systemd читает файлы конфигурации из обоих этих
 		каталогов, но файлы из +/etc+ (управляемые системным
 		администратором) имеют приоритет над файлами из +/lib+ (которые
-		управляются пакетным менеджером). Таким образом, созание
+		управляются пакетным менеджером). Таким образом, создание
 		символьной ссылки (или обычного файла)
 		+/etc/systemd/system/ntpd.service+ предотвращает чтение
 		штатного файла конфигурации +/lib/systemd/system/ntpd.service+.
@@ -1090,7 +1090,7 @@ systemd и на этот случай есть простое решение, и
 		(через механизмы sudo или PolicyKit) право на использование
 		+systemctl+, это еще не~означает, что он сможет запустить
 		заблокированную службу~--- права на выполнение +rm+ (удаление
-		блокирующей символьной ссылки) выдаются отдельно}.
+		блокирующей символьной ссылки) выдаются отдельно.}.
 \end{itemize}
 
 После прочтения изложенного выше, у читателя может возникнуть вопрос: как
@@ -1165,10 +1165,10 @@ chroot в самой программе. Прежде всего, коррект
 chroot-окружения требует глубокого понимания принципов работы программы.
 Например, нужно точно знать, какие сокеты использует программа, чтобы обеспечить
 bind-монтирование соответствующих каталогов. С учетом вышесказанного,
-эффективный chroot-защита обеспечивается в том случае, когда она реализована в
-коде самого демона. Именно разработчик лучше других знает (\emph{обязан знать}),
+эффективная chroot-защита обеспечивается в том случае, когда она реализована в
+коде самого демона. Именно разработчик лучше других знает (\emph{обязан} знать),
 как правильно сконфигурировать chroot-окружение, и какой минимальный набор
-файлов, каталогов и файловых систем необходим внутри для нормальной работы
+файлов, каталогов и файловых систем необходим внутри него для нормальной работы
 демона. Уже сейчас существуют демоны, имеющие встроенную поддержку chroot.
 К сожалению, в системе Fedora, установленной с параметрами по умолчанию, таких
 демонов всего два: \href{http://avahi.org/}{Avahi} и RealtimeKit. Оба они
@@ -1212,7 +1212,7 @@ RootDirectoryStartOnly=yes
 командой +systemctl start foobar.service+. Информацию о его текущем состоянии
 можно получить с помощью команды +systemctl status foobar.service+. Команды
 управления и мониторинга службы не~зависят от того, запущена ли она в chroot'е,
-или нет. Этим systemd отличается от класического SysV init.
+или нет. Этим systemd отличается от классического SysV init.
 
 Новые ядра Linux поддерживают возможность создания независимых пространств имен
 файловых систем (в дальнейшем FSNS, от <<file system namespaces>>). По
@@ -1240,7 +1240,7 @@ InaccessibleDirectories=/home
 защитить данные пользователей от потенциальных хакеров. (Подробнее об этих
 опциях можно почитать на
 \href{http://0pointer.de/public/systemd-man/systemd.exec.html}{странице
-руководства}).
+руководства}.)
 
 Фактически, FSNS по множеству параметров превосходят +chroot()+. Скорее всего,
 Avahi и ReltimeKit в ближайшем будущем перейдут с +chroot()+ к использованию
@@ -1287,7 +1287,7 @@ systemd имеет целый ряд возможностей, полезных
 debootstrap/febootstrap. В этом случае возможности +systemctl+ ограничиваются
 операциями с символьными ссылками, определяющими триггеры активации юнитов, т.е.
 выполнением действий +enable+ и +disable+, не~требующих непосредственного
-взаимодействия с процессом init}.
+взаимодействия с процессом init.}.
 
 Однако, куда более интересные возможности предоставляет программа
 \href{http://0pointer.de/public/systemd-man/systemd-nspawn.html}{systemd-nspawn},
@@ -1305,7 +1305,7 @@ Linux, которая позиционируется как современна
 настроек и т.п., в то время как +systemd-nspawn+ является лишь более удобной и
 эффективной заменой команды +chroot(1)+, предназначенной прежде всего для
 развертывания, восстановления, сборки и тестирования операционных систем. Далее
-автор разъясняет свою точку зрения на этот вопрос}.
+автор разъясняет свою точку зрения на этот вопрос.}.
 +systemd-nspawn+ проста в использовании как +chroot(1)+, однако изоляция
 от хост-системы является более полной и безопасной. Всего одной командой
 вы можете загрузить внутри контейнера \emph{полноценную} ОС (на базе systemd
@@ -1378,7 +1378,7 @@ systemd уже подготовлен для работы внутри таки
 		наилучший результат, когда оно реализовано непосредственно в
 		коде самой программы.
 	\item +ReadOnlyDirectories=+ и +InaccessibleDirectories=+ могут быть
-		удобной альтернативой созданию полноценных chroot-окружений.
+		удобной альтернативой созданию полновесных chroot-окружений.
 	\item Если вам нужно поместить в chroot-окружение какую-либо службу,
 		воспользуйтесь опцией +RootDirectory=+.
 	\item +systemd-nspawn+~--- очень неплохая штука.
@@ -1564,10 +1564,85 @@ cryptsetup, что снижение этого времени с 1 секунд
 завершится процесс монтирования? Это можно сделать, воспользовавшись магической
 силой systemd~--- просто добавим опцию монтирования +comment=systemd.automount+
 в +/etc/fstab+. После этого, systemd будет создавать в +/home+ точку
-автоматического монтирования, и при первом же обращении к этому каталогу
-systemd выполнит подготовку устройства, проверку и монтирование файловой
-системы.
+автоматического монтирования, и при первом же обращении к этому каталогу,
+если файловая система еще не~будет готова к работе,
+systemd подготовит соответствующее устройство, проверит и смонтирует ее.
 
+После внесения изменений в +/etc/fstab+ и перезагрузки мы получаем:
+\begin{Verbatim}
+systemd[1]: Startup finished in 2s 47ms 112us (kernel) + 2s 663ms 942us (initrd)
++ 5s 540ms 522us (userspace) = 10s 251ms 576us.
+\end{Verbatim}
+
+Прекрасно! Несколькими простыми действиями мы выиграли почти семь секунд. И эти
+два изменения исправляют только две наиболее очевидные проблемы. При более
+аккуратном и детальном исследовании, обнаружится еще множество моментов, которые
+можно улучшить. Например, на другом моем компьютере, лаптопе X300 двухлетней
+давности (и даже два года назад он был не~самым быстрым на Земле), после
+небольшой доработки, время загрузки до полноценной среды GNOME
+составило около четырех секунд, и это еще не~предел совершенства.
+
++systemd-analyze blame+~--- простой и удобный инструмент для поиска медленно
+запускающихся служб, однако он обладает одним существенным недостатком: он
+не~показывает, насколько эффективно параллельный запуск снижает потерю времени
+для медленно запускающихся служб. Чтобы вы могли наглядно оценить этот фактор,
+мы подготовили команду +systemd-analyze plot+. Использовать ее очень просто:
+\begin{Verbatim}
+$ systemd-analyze plot > plot.svg
+$ eog plot.svg
+\end{Verbatim}
+
+Она создает наглядные диаграммы, показывающие моменты запуска служб и время,
+затраченное на их запуск, по отношению к другим службам. На текущий момент, она
+не~показывает явно, кто кого ожидает, но догадаться обычно несложно.
+
+Чтобы продемонстрировать эффект, порожденный двумя нашими оптимизациями,
+приведем ссылки на соответствующие графики:
+\href{http://0pointer.de/public/blame.svg}{до} и
+\href{http://0pointer.de/public/blame2.svg}{после} (для полноты описания приведем также и
+соответствующие данные +systemd-analyze blame+:
+\href{http://0pointer.de/public/blame.txt}{до} и
+\href{http://0pointer.de/public/blame2.txt}{после}).
+
+У наиболее эрудированных читателей может возникнуть вопрос: как это соотносится с
+программой \href{https://github.com/mmeeks/bootchart}{bootchart}? Действительно,
++systemd-analyze plot+ и +bootchart+ рисуют похожие графики. Однако, bootchart
+является намного более мощным инструментом~--- он детально показывает, что
+именно происходило во время загрузки, и отображает соответствующие графики
+использования процессора и ввода-вывода. +systemd-analyze plot+ оперирует более
+высокоуровневой информацией: сколько времени затратила та или иная служба во
+время запуска, и какие службы были вынуждены ее ожидать. Используя оба эти
+инструмента, вы значительно упростите себе поиск причин замедления вашей
+загрузки.
+
+Но прежде, чем вы вооружитесь описанными здесь средствами и начнете
+отправлять багрепорты авторам и сопровождающим программ, которые замедляют вашу
+загрузку, обдумайте все еще раз. Эти инструменты предоставляют вам <<сырую>>
+информацию. Постарайтесь не~ошибиться, интерпретируя ее. Например, в
+при рассмотрении приведенного выше примера я показал, что проблема была вовсе
+не~в +udev-settle.service+, и не~в опросе устройств для ModemManager'а, а в 
+неудачной реализации подсистемы хранения, требующей ожидать окончания опроса
+устройств для продолжения загрузки. Именно эту проблему и нужно исправлять.
+Поэтому постарайтесь правильно определить источник проблем. Возлагайте вину на
+тех, кто действительно виноват.
+
+Как уже говорилось выше, все три описанных здесь инструмента доступны в
+Fedora~15 <<из коробки>>.
+
+Итак, какие же выводы мы можем сделать из этой истории?
+\begin{itemize}
+	\item +systemd-analyze+~--- отличный инструмент. Фактически, это
+		встроенный профилировщик systemd.
+	\item Постарайтесь не~ошибиться, интерпретируя вывод профилировщика!
+	\item Всего два небольших изменения могут ускорить загрузку системы на
+		семь секунд.
+	\item Программное обеспечение, не~способное работать с динамически
+		меняющимся набором устройств, создает проблемы, и должно быть
+		исправлено.
+	\item Принудительное использование в стандартной установке Fedora~15
+		промышленной реализации подсистем хранения, возможно, является
+		не~самым правильным решением.
+\end{itemize}
 
 \end{document}