Утилита systemd-analyze, являясь составной частью системного менеджера systemd, входит в состав одноимённого пакета и присутствует в любой системе, её использующей. Тратить man-страницу на такую мелочь ни кто не стал, поэтому представление о возможностях команды получаем, запустив её из командной строки с обычной для этого случая опцией:

$ systemd-analyze --help

Вывод её, конечно, не потрясёт нас обилием возможностей:

systemd-analyze time
systemd-analyze blame
systemd-analyze plot

Но ведь большего нам и не требуется, верно?

Опция time используется по умолчанию. То есть при её указании, как и просто при команде

$ systemd-analyze

последует вывод вроде такого:

Startup finished in 4133ms (kernel) + 2694ms (userspace) = 6827ms

Нетрудно догадаться, что первое значение — это время загрузки ядра и модулей, использующих пространство памяти ядра, второе — загрузка стартовых сервисов в пользовательское пространство.

Обращаем внимание, что, по сравнению с показаниями секундомера, команда systemd-analyze льстит системе, загружаемой в стиле systemd, более чем два раза: как мы помним по прошлой странице, время её загрузки, измеренное «по старинке», составило 15,5 секунды).

Не отсюда ли происходит легенда о двухкратном ускорении загрузки через systemd по сравнению с sysv? Если первую мерять с помощью собственной утилиты, а вторую, в которой эта утилита, разумеется, не работает, то примерно такой результат мы и получаем…

Но не будем обвинять других в том, что мы отвергли в свой адрес — в неспортивном поведении. А лучше посмотрим, из чего складывается время загрузки при использвоании systemd. Одну составляющую — загрузку ядра и модулей — мы уже выявили. И она составляет более половины суммарного времени загрузки. А долю компонентов, загружаемых в пользовательское пространство памяти, можно определить, дав ту же команду в такой форме:

$ systemd-analyze blame

На что последует вывод вида

  1012ms bootsplash-quit.service
   743ms systemd-readahead-replay.service
...

и так далее. Весь его не привожу, ибо я выплолнял эту команду на системе со стартовыми сервисами по умолчанию, без всякой чистки. И потому он получится очень длинным. Обращу внимание только на некоторые моменты.

Первое — командная конструкция

$ systemd-analyze blame | grep splash

выдаст нам всё, что имеет отношение к сплэшу:

1011ms bootsplash-quit.service
    40ms bootsplash-startup.service
    18ms splash_early.service
    12ms splash.service

Результат интересен тем, что сплэш этот самый отъедает изрядную часть времени при старте системы.

Не менее интересен вывод конструкции, отфильтровывающей сетевые сервисы:

$ systemd-analyze blame | egrep 'net|ntp'                                              22:46 pts/0
    76ms localnet.service
    26ms ntp.service
    21ms network.service

Дело в том, что, когда я говорил о лёгкости и безболезненности переключения между стилями инциацилизации, я говорил чистую правду. Но не всю правду. Которая состоит в том, что при переключении стиля загрузки с systemd на sysv не все службы стартуют автоматически — в частности, в загруженной системе мы не увидим поддержки сети (это легко исправить, но к теме нашего разговора не относится).

Видимо, этим и объясняются те самые, достаточно постоянные 100 миллисекунд разницы между временем загрузки в разных стилях. Прямо это проверить невозможно, потому как при переключении на sysv команда systemd-analyze, разумеется, не выдаст нам ничего, кроме ошибок.

А вот 9 секунд разницы, полученные при запуске системы с HDD ноутбука, выпадением из загрузки стартовых сервисов объяснить нельзя. И не по причине величины расхождения. А потому, что на ноуте измерения проводились не при временном переключении стилей загрузки через меню GRUB’а, а при постоянном переходе на инициализацию в стиле sysv, как это было описано ранее в одном из набросков http://suseana.ml/?p=94. Когда все необходимые стартовые сервисы стартовали как положено.

Кстати говоря, абсолютным значениям показаний systemd-analyze слишком большого значения придавать не нужно: после каждого рестарта машины они оказываются несколько разными, хотя масштаб величин более-менее сохраняется — собирать статистику по этому вопросу мне откровенно лень.

Таким образом, хотя напрямую сравнить скорость запуска при systemd и sysv, измеренную, так сказать, инструментально, и не удалось, косвенные данные свидетельствуют, что при размещении системы на современном быстром SSD разницы в скорости загрузки в зависимости от её стиля нет. И потому чисто волюнтаристически его я и объявляю единоличным победителем данного забега.

Тем не менее, systemd-analyze даёт интересную информацию к размышлению, если продолжать думать об уменьшении времени загрузки, вне зависимости от используемой схемы инициализации. К этому вопросу я вернусь, когда (и если) мой врождённый азарт пересилит моё столь же мою и столь же врождённую лень. Союзником которой в данном случае выступает благоприобретённый здравый смысл. Постоянно напоминающий мне, что все эти скорости загрузки — такая фигня, о которой просто смешно говорить…

А вот то, что резиновую жабу скорости загрузки надувают до размеров общесистемного дирижабля (см. старую песню Владимира Асмолова, пруфа не будет, ибо sapienti sat) — это уже не фигня. И к этой-то теме я вернусь обязательно, и, надеюсь, что скоро. Только уже не здесь, а на братском Блогосайте, наверное.


К содержанию