Ускорение загрузки: профиль systemd-analyze
Ускорить загрузку Arch Linux можно, но сначала измерь, где именно теряется время. Для этого есть systemd-analyze: встроенная утилита systemd, которая показывает тайминги загрузки, список самых медленных юнитов и критический путь. Запусти systemd-analyze time, посмотри на цифры, потом отключай то, что реально тормозит. Типичный выигрыш, от пары до десяти секунд, без риска сломать систему.
Что показывает systemd-analyze time
Первая команда, самая простая:
systemd-analyze time
Вывод выглядит примерно так:
Startup finished in 3.847s (firmware) + 1.204s (loader) + 1.531s (kernel) + 5.218s (userspace) = 11.800s
graphical.target reached after 5.218s in userspace.
Четыре числа, четыре фазы загрузки:
firmware: время от включения питания до передачи управления загрузчику. Это BIOS/UEFI, и systemd на него не влияет. Если тут десять секунд: проблема в прошивке, а не в системе.loader: время работы загрузчика (GRUB, systemd-boot). Зависит от конфигурации и скорости чтения.kernel: инициализация ядра до запуска первого процесса systemd.userspace: время от старта systemd до достиженияgraphical.target. Здесь живут почти все узкие места, которые можно убрать.
Запускай команду после свежей загрузки, а не после долгой работы системы, цифры относятся к последней загрузке. Если ты только что что-то менял, перезагрузись и смотри заново.
Если userspace занимает больше половины общего времени, есть смысл копать дальше. Если всё время съедает firmware, ускорять нечего, разве что настройки UEFI.
Как найти узкое место
systemd-analyze blame: список самых медленных юнитов
systemd-analyze blame
Команда выводит юниты, отсортированные по времени активации, от самых медленных к быстрым:
5.218s NetworkManager-wait-online.service
2.104s systemd-journal-flush.service
1.531s systemd-fsck-root.service
0.847s ldconfig.service
Первые строки: кандидаты на отключение. Но не спеши: blame показывает время работы каждого юнита по отдельности, а не его вклад в общую загрузку. Юнит может работать долго, но параллельно с другими, и на скорость входа в систему не влиять.
systemd-analyze critical-chain: критический путь
Вот это важнее:
systemd-analyze critical-chain
Критический путь: цепочка юнитов, которые обязаны выполниться строго друг за другом, прежде чем появится graphical.target. Сократишь любой юнит из цепочки, загрузка станет короче ровно на это время. Юниты вне цепочки работают параллельно и на общее время почти не влияют.
Вывод выглядит так:
graphical.target @5.218s
└─multi-user.target @5.218s
└─NetworkManager-wait-online.service @5.218s +5.218s
└─NetworkManager.service @1.204s
└─dbus.service @1.203s
└─basic.target @1.202s
Видно, что NetworkManager-wait-online.service висит в цепочке и держит загрузку пять секунд. Убираешь его, и graphical.target достигается почти сразу.
systemd-analyze plot: картинка вместо цифр
systemd-analyze plot > boot.svg
Получится SVG-график, где каждый юнит, полоска на временной шкале. Открой файл в браузере: сразу видно, какие юниты тянутся долго, а какие ждут других. Удобно, когда юнитов много и текстовый вывод не читается.
Сравнивай до и после
Сохрани вывод systemd-analyze time до изменений и после каждого шага. Так ты увидишь реальный эффект, а не ощущения. Пять секунд, которые казались «быстрее», легко проверить цифрами.
Что отключить, чтобы ускорить загрузку
NetworkManager-wait-online.service: классический тормоз
Этот сервис ждёт, пока сеть станет доступной, и только потом разрешает продолжать загрузку. На десктопе он почти всегда не нужен, сеть поднимется и без него, просто чуть позже.
systemctl disable --now NetworkManager-wait-online.service
Затем critical-chain станет заметно короче. Если сеть нужна для монтирования сетевых шары из fstab, сервис оставь.
Ненужные сервисы
Посмотри, чем реально пользуешься. Bluetooth не нужен, если нет bluetooth-устройств:
systemctl disable --now bluetooth.service
CUPS не нужен, если нет принтера:
systemctl disable --now cups.service
Правило простое: отключай только то, чем не пользуешься. Не отключай сервисы «на всякий случай», потом будешь гадать, почему не работает Wi-Fi или печать.
Полный список включённых сервисов:
systemctl list-unit-files --state=enabled
Пройдись по списку глазами: половину имён ты, скорее всего, не узнаешь. Это нормально: многие сервисы нужны системе. Отключай только те, назначение которых понимаешь.
Проверяй результат после каждого шага
После каждого отключения перезагружайся и смотри systemd-analyze time. Так ты увидишь реальный эффект каждого изменения и поймёшь, что сработало, а что нет.
Как ускорить fstab и fsck
Проверка файловых систем
systemd-fsck-root.service проверяет корневой раздел при каждой загрузке. На больших дисках это секунды. Сначала посмотри, сколько времени она занимает:
systemd-analyze critical-chain | grep fsck
Для теста можно добавить в параметры ядра fsck.mode=skip, но это временная мера. Постоянно отключать проверку корня не стоит: при сбое питания fsck единственная защита от повреждения данных.
Размер раздела тоже влияет: на маленьком корне проверка проходит за долю секунды, на большом заметно дольше. Если systemd-fsck-root стабильно висит в critical-chain, а раздел большой, подумай, нужна ли проверка при каждой загрузке.
Съёмные разделы
Если в fstab есть флешки или внешние диски, которые не всегда подключены, systemd ждёт их появления. Добавь опцию nofail в строку монтирования:
UUID=xxxx-xxxx /mnt/usb vfat rw,nofail 0 0
С nofail система не ждёт отсутствующий раздел и продолжает загрузку.
Как перенести сервисы после загрузки
Некоторые сервисы нужны, но не обязаны стартовать до входа в систему. Например, медленный демон, от которого ничего не зависит. Если юнит запускается через multi-user.target, он тянет загрузку. Перенеси его на default.target:
[Install]
WantedBy=default.target
Затем:
systemctl daemon-reload
systemctl reenable имя-сервиса
Сервис стартует после входа в систему, а не во время загрузки. Работает для type=forking демонов, которые сами уходят в фон. Для сервисов, от которых зависят другие юниты, такой трюк не подходит. То же самое касается systemd-tmpfiles и подобных одноразовых задач, им не место в критическом пути.
Как ускорить параллельность загрузки
systemd запускает независимые юниты параллельно. Проблемы начинаются, когда юниты выстраиваются в цепочку через Requires= или After=. Чем длиннее цепочка, тем дольше загрузка: каждый следующий юнит ждёт предыдущий.
Проверь зависимости своего сервиса:
systemctl list-dependencies имя-сервиса
Если сервис тянет за собой лишние зависимости, убери их из юнита. Чаще всего достаточно After= без Requires=: юнит запустится после, но не будет блокировать загрузку, если зависимость не готова.
Не добавляй Requires= без необходимости. По умолчанию systemd и так тянет базовые цели (basic.target, sysinit.target): этого хватает в большинстве случаев.
Что даёт ядро и initramfs
Параметры ядра
Параметр quiet скрывает вывод ядра и немного ускоряет загрузку за счёт меньшего количества логов. Параметр mitigations=off отключает защиту от уязвимостей процессора, он ускоряет систему, но снижает безопасность, поэтому решай сам. Подробнее про параметры в статье «Параметры ядра: командная строка».
Initramfs
Длинный initramfs дольше распаковывается и дольше инициализируется. Хук autodetect собирает образ только под текущее железо: это сильно уменьшает размер. Разбор хуков в статье «mkinitcpio подробно: хуки и модули».
Старые ядра
Каждое установленное ядро добавляет время на этапе загрузчика и увеличивает initramfs. Если в меню GRUB пять ядер, а нужны два: остальные можно удалить. Как сделать это безопасно в статье «Чистка старых ядер и initramfs».
Гибернация и swap
Если используешь гибернацию, ядро при загрузке ищет образ сна в swap-разделе. На медленном или большом swap это добавляет время. Если гибернация не нужна, убери параметр resume= из параметров ядра, и загрузка перестанет ждать образ сна.
Сколько реально можно выиграть
Честно: чудес не бывает. На практике чаще всего удаётся убрать от пары до десяти секунд. Пять секунд на NetworkManager-wait-online, пара секунд на fsck, секунда на лишний сервис: вот и весь профит. Если загрузка и так занимает восемь секунд, а ты гоняешься за последней секундой, остановись. Стабильность дороже.
Не гонись за миллисекундами ценой отказа от проверки файловых систем или отключения нужных сервисов. Измеряй, отключай лишнее, проверяй после каждого шага:
systemd-analyze time
Главное: не превращать ускорение в хобби. Одна проверка systemd-analyze time раз в месяц: нормально. Перезагрузка ради каждой десятой доли секунды: уже нет.
Частые вопросы
systemd-analyze blame показывает большой systemd-journal-flush: это нормально?
Да. systemd-journal-flush.service переносит журнал из памяти на диск. Он часто выглядит медленным в blame, но почти всегда работает параллельно с другими юнитами и не влияет на критический путь. Проверь critical-chain, если его там нет, трогать не нужно.
Можно ли ускорить фазу firmware?
Нет, systemd на неё не влияет. Фирмварь работает до загрузчика. Можно попробовать отключить ненужные устройства в UEFI, обновить прошивку или включить быструю загрузку, но это уже не про systemd.
Что делать, если после отключения сервиса что-то сломалось?
Верни сервис обратно:
systemctl enable --now имя-сервиса
Ничего страшного не произойдёт. Отключение сервиса: обратимая операция, в отличие от удаления пакета.
Стоит ли отключать systemd-fsck-root?
Нет. Проверка корневого раздела защищает от повреждений после сбоя питания. fsck.mode=skip используй только для теста, чтобы понять, сколько времени она занимает.
systemd-analyze показывает быструю загрузку, но система грузится долго?
Значит, узкое место вне systemd. Смотри фазы firmware и loader: медленный BIOS, долгий поиск загрузочных устройств, задержка в GRUB. systemd-analyze тут бессилен, копать нужно в сторону UEFI и загрузчика.
Полезные ресурсы
- Improving boot time, ArchWiki: полное руководство по ускорению загрузки.
- Systemd, ArchWiki: документация по systemd и systemd-analyze.
- Остановка загрузки: диагностика таймингов: разбор таймингов из этой же серии статей.
Заключение
systemd-analyze: главный инструмент для ускорения загрузки. Сначала time, общая картина, потом blame и critical-chain: узкие места, затем plot, наглядная картинка. Отключай только лишнее: NetworkManager-wait-online, неиспользуемые сервисы, ждущие разделы в fstab. Реальный выигрыш, от пары до десяти секунд. Измеряй после каждого шага и не ломай стабильность ради миллисекунд.
Не получилось? Поможем настроить
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии