Version v5.0 (2011-05-14 17:53) [AUTO]

s4a.tex

@@ -1388,6 +1388,76 @@ 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}
+
 \end{document}
 
 vim:ft=tex:tw=80:spell:spelllang=ru