Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Сразу к делу: ускорить загрузку Arch Linux можно, но сначала измерь, где именно теряется время. Для этого есть systemd-analyze — встроенная утилита systemd, которая показывает тайминги загрузки, список самых медленных юнитов и критический путь. Запусти 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
Команда выводит юниты, отсортированные по времени активации, от самых медленных к быстрым:
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
Критический путь — цепочка юнитов, которые обязаны выполниться строго друг за другом, прежде чем появится 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 > boot.svg
Получится SVG-график, где каждый юнит — полоска на временной шкале. Открой файл в браузере: сразу видно, какие юниты тянутся долго, а какие ждут других. Удобно, когда юнитов много и текстовый вывод не читается.
Сохрани вывод systemd-analyze time до изменений и после каждого шага. Так ты увидишь реальный эффект, а не ощущения. Пять секунд, которые казались «быстрее», легко проверить цифрами.
Этот сервис ждёт, пока сеть станет доступной, и только потом разрешает продолжать загрузку. На десктопе он почти всегда не нужен — сеть поднимется и без него, просто чуть позже.
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. Так ты увидишь реальный эффект каждого изменения и поймёшь, что сработало, а что нет.
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) — этого хватает в большинстве случаев.
Параметр quiet скрывает вывод ядра и немного ускоряет загрузку за счёт меньшего количества логов. Параметр mitigations=off отключает защиту от уязвимостей процессора — он ускоряет систему, но снижает безопасность, поэтому решай сам. Подробнее про параметры — в статье «Параметры ядра: командная строка».
Длинный initramfs дольше распаковывается и дольше инициализируется. Хук autodetect собирает образ только под текущее железо — это сильно уменьшает размер. Разбор хуков — в статье «mkinitcpio подробно: хуки и модули».
Каждое установленное ядро добавляет время на этапе загрузчика и увеличивает initramfs. Если в меню GRUB пять ядер, а нужны два — остальные можно удалить. Как сделать это безопасно — в статье «Чистка старых ядер и initramfs».
Если используешь гибернацию, ядро при загрузке ищет образ сна в swap-разделе. На медленном или большом swap это добавляет время. Если гибернация не нужна — убери параметр resume= из параметров ядра, и загрузка перестанет ждать образ сна.
Честно: чудес не бывает. На практике чаще всего удаётся убрать от пары до десяти секунд. Пять секунд на NetworkManager-wait-online, пара секунд на fsck, секунда на лишний сервис — вот и весь профит. Если загрузка и так занимает восемь секунд, а ты гоняешься за последней секундой — остановись. Стабильность дороже.
Не гонись за миллисекундами ценой отказа от проверки файловых систем или отключения нужных сервисов. Измеряй, отключай лишнее, проверяй после каждого шага:
systemd-analyze time
Главное — не превращать ускорение в хобби. Одна проверка systemd-analyze time раз в месяц — нормально. Перезагрузка ради каждой десятой доли секунды — уже нет.
Да. systemd-journal-flush.service переносит журнал из памяти на диск. Он часто выглядит медленным в blame, но почти всегда работает параллельно с другими юнитами и не влияет на критический путь. Проверь critical-chain — если его там нет, трогать не нужно.
Нет, systemd на неё не влияет. Фирмварь работает до загрузчика. Можно попробовать отключить ненужные устройства в UEFI, обновить прошивку или включить быструю загрузку — но это уже не про systemd.
Верни сервис обратно:
systemctl enable --now имя-сервиса
Ничего страшного не произойдёт. Отключение сервиса — обратимая операция, в отличие от удаления пакета.
Нет. Проверка корневого раздела защищает от повреждений после сбоя питания. fsck.mode=skip используй только для теста, чтобы понять, сколько времени она занимает.
Значит, узкое место вне systemd. Смотри фазы firmware и loader: медленный BIOS, долгий поиск загрузочных устройств, задержка в GRUB. systemd-analyze тут бессилен — копать нужно в сторону UEFI и загрузчика.
systemd-analyze — главный инструмент для ускорения загрузки. Сначала time — общая картина, потом blame и critical-chain — узкие места, затем plot — наглядная картинка. Отключай только лишнее: NetworkManager-wait-online, неиспользуемые сервисы, ждущие разделы в fstab. Реальный выигрыш — от пары до десяти секунд. Измеряй после каждого шага и не ломай стабильность ради миллисекунд.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии