Version v5.1 (2011-05-14 18:48) [AUTO]

s4a.tex

@@ -1388,6 +1388,108 @@ systemd уже подготовлен для работы внутри таки
 
 И все это уже сейчас доступно в Fedora~15.
 
+\section{Поиск виновных}
+
+Fedora~15\footnote{Также известный как величайший в истории релиз свободной ОС}
+является первым релизом Fedora, использующим systemd в качестве системы
+инициализации по умолчанию. Основной нашей целью при работе над выпуском F15
+является обеспечение полной взаимной интеграции и корректной работы всех
+компонентов. При подготовке следующего релиза, F16, мы сконцентрируемся на
+дальнейшей полировке и ускорении системы. Для этого мы подготовили ряд
+инструментов (доступных уже в F15), которые должны помочь нам в поиске проблем,
+связанных с процессом загрузки. В этой статье я попытаюсь рассказать о том, как
+найти виновников медленной загрузки вашей системы, и о том, что с ними делать
+дальше. Мы хотим помочь вам в поиске тех системных компонентов, которые являются
+причинами ваших проблем.
+
+Первый инструмент, который мы можем вам предложить, очень прост: по завершении
+загрузки, systemd регистрирует в системном журнале информацию о суммарном
+времени загрузки:
+\begin{Verbatim}
+systemd[1]: Startup finished in 2s 65ms 924us (kernel) + 2s 828ms 195us (initrd)
++ 11s 900ms 471us (userspace) = 16s 794ms 590us.
+\end{Verbatim}
+
+Эта запись означает следующее: на инициализацию ядра (до момента запуска initrd,
+т.е. dracut) ушло 2 секунды. Далее, чуть менее трех секунд работал initrd. И
+наконец, почти 12 секунд было потрачено systemd на запуск программ из
+пространства пользователя. Итоговое время, начиная с того момента, как
+загрузчик передал управление коду ядра, до того момента, как systemd завершил
+все операции, связанные с загрузкой системы, составило почти 17 секунд.
+Казалось бы, смысл этого числа вполне очевиден, однако не~стоит делать поспешных
+выводов. Прежде всего, в нем не~учитывается время, затраченное на инициализацию
+вашего сеанса в GNOME, так как эта задача уже выходит за рамки задач процесса
+init. Кроме того, в этом периоде времени учитывается только работа systemd, хотя
+часто бывает так, что некоторые демоны продолжают \emph{свою} работу по
+инициализации уже после того, как секундомер остановлен. Проще говоря:
+предложенные вам числа позволяют лишь оценить общую скорость загрузки, однако
+они не~являются точной характеристикой длительности процесса.
+
+Кроме того, эта информация носит поверхностный характер: она не~сообщает, какие
+именно системные компоненты заставляют systemd ждать так долго. Чтобы исправить 
+это упущение, мы ввели команду +systemd-analyze blame+:
+\begin{Verbatim}
+$ systemd-analyze blame
+  6207ms udev-settle.service
+  5228ms cryptsetup@luks\x2d9899b85d\x2df790\x2d4d2a\x2da650\x2d8b7d2fb92cc3.service
+   735ms NetworkManager.service
+   642ms avahi-daemon.service
+   600ms abrtd.service
+   517ms rtkit-daemon.service
+   478ms fedora-storage-init.service
+   396ms dbus.service
+   390ms rpcidmapd.service
+   346ms systemd-tmpfiles-setup.service
+   322ms fedora-sysinit-unhack.service
+   316ms cups.service
+   310ms console-kit-log-system-start.service
+   309ms libvirtd.service
+   303ms rpcbind.service
+   298ms ksmtuned.service
+   288ms lvm2-monitor.service
+   281ms rpcgssd.service
+   277ms sshd.service
+   276ms livesys.service
+   267ms iscsid.service
+   236ms mdmonitor.service
+   234ms nfslock.service
+   223ms ksm.service
+   218ms mcelog.service
+...
+\end{Verbatim}
+
+Она выводит список юнитов systemd, активированных при загрузке, с указанием
+времени инициализации для каждого из них. Список отсортирован по убыванию этого
+времени, поэтому наибольший интерес для нас представляют первые строчки. В нашем
+случае это +udev-settle.service+ и
++cryptsetup@luks\x2d9899b85d\x2df790\x2d4d2a\x2da650\x2d8b7d2fb92cc3.service+,
+инициализация которых занимает более одной секунды. Стоит отметить, что к
+анализу вывода команды +systemd-analyze blame+ тоже следует подходить с
+осторожностью: она не~поясняет, \emph{почему} тот или иной юнит тратит
+столько-то времени, она лишь констатирует факт, что время было затрачено. Кроме
+того, не~стоит забывать, что юниты могут запускаться параллельно. В частности,
+если две службы были запущены одновременно, то время их инициализации будет
+значительно меньше, чем сумма времен инициализации каждой из них.
+
+Рассмотрим повнимательнее первого осквернителя нашей загрузки: службу
++udev-settle.service+. Почему ей требуется так много времени для запуска, и что
+мы можем с этим сделать? Эта служба выполняет очень простую задачу: она ожидает,
+пока udev завершит опрос устройств, после чего завершается. Опрос же устройств
+может занимать довольно много времени. Например, в нашем случае опрос устройств
+занимает более 6~секунд из-за встроенного в компьютер 3G-модема, в котором
+отсутствует SIM-карта. Этот модем очень долго отвечает на запросы udev. Опрос
+устройств является частью схемы, обеспечивающей работу ModemManager'а и
+позволяющей NetworkManager'у упростить для вас настройку 3G. Казалось бы,
+очевидно, что виновником задержек является именно ModemManager, так как опрос
+устройств для него занимает слишком много времени. Но такое обвинение будет
+заведомо ошибочным. Дело в том, что опрос устройств вообще является довольно
+длительной процедурой. Медленный опрос 3G-устройств для ModemManager является
+частным случаем, отражающим это общее правило. Хорошая система опроса устройств
+обязательно должна учитывать тот факт, что операция опроса любого из устройств
+может затянуться надолго. Истинной причиной наших проблем является тот факт,
+что мы должны ожидать завершения опроса устройств, т.е., наличие
++udev-settle.service+ как обязательной части нашего процесса загрузки.
+
 \end{document}
 
 vim:ft=tex:tw=80:spell:spelllang=ru