Оптимизация времени загрузки в Linux: Практические методы анализа и настройки systemd

Время загрузки системы редко становится фокусом инженерной оптимизации, пока не превращается в досадную проблему. Разработчики, которые перезагружают системы по несколько раз в день — будь то из-за обновления ядра, тестирования сервисов или аппаратного сброса — часто тратят непроизводительные минуты на ожидание инициализации демонов. В этой статье разберем методы анализа зависимостей systemd, скриптов initramfs и параметров ядра для сокращения времени старта системы на примере Arch Linux.

Бенчмаркинг и диагностика узких мест

Начните с объективных измерений. Инструмент systemd-analyze предоставляет метрики для каждого этапа загрузки:

$ systemd-analyze time
Startup finished in 4.891s (kernel) + 8.732s (initrd) + 12.306s (userspace) = 25.93s 

Но реальная ценность — в детализации по юнитам. Команда systemd-analyze critical-chain выделяет последовательность блокирующих задач:

$ systemd-analyze critical-chain graphical.target
graphical.target @12.306s
└─multi-user.target @12.305s
  └─docker.service @5.214s +789ms
    └─network-online.target @5.212s
      └─NetworkManager-wait-online.service @3.921s +1.290s

Здесь явная проблема: Docker запускается раньше, чем завершается инициализация сети. В реальных сценариях такие зависимости часто становятся скрытым техническим долгом, когда сервисы в userspace неверно объявлены в unit-файлах.

Дополните анализ визуализацией графа зависимостей через systemd-analyze dot | dot -Tsvg > graph.svg. Визуальный осмотр помогает выявить неочевидные связи, например, сервисы, синхронно ожидающие монтирования удаленных NFS-ресурсов.

Оптимизация Userland: Отключаем, маскируем, переупорядочиваем

Список всех юнитов, стартующих при загрузке:

$ systemctl list-unit-files --state=enabled

Типичные кандидаты на отключение:

• Устаревшие сервисы (пример: bluetooth.service на сервере)
• Overlay-сервисы вроде modemmanager.service
• Демоны управления питанием (tlp.service в某些 конфигурациях)

Маскирование vs. Остановка:
Используйте systemctl mask вместо disable, когда необходимо гарантировать, что сервис не будет запущен даже как зависимость других юнитов. Например, маскировка apt-daily.service в десктопных сборках предотвращает фоновые обновления, вмешивающиеся в рабочий процесс.

Корректировка порядка запуска:
Добавление After=network.target в [Unit] секцию сервиса гарантирует, что сетевой стек инициализирован до его запуска. Однако для асинхронной загрузки рассмотрите использование Type=idle, если сервис может стартовать в фоне.

Initramfs и ядро: Ускоряем низкоуровневую инициализацию

Время, проведенное в initramfs, часто обусловлено ожиданием аппаратных устройств. Для анализа:

$ dmesg -T | grep 'initramfs'

Если в выводе присутствуют таймауты в ожидании LVM или RAID-массивов, измените параметры загрузки ядра в /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="rd.timeout=5"

Для систем с Btrfs добавьте rootflags=skip-subvolume-on-relocation для ускорения проверок целостности.

Модули ядра: Минимизируйте список загружаемых модулей через /etc/mkinitcpio.conf. Например, удаление ненужных драйверов SCSI или устаревших WiFi-чипсетов сократит размер initramfs и время его распаковки.

Параллелизация и атомарные операции

Systemd по умолчанию использует параллельный запуск юнитов, но зависимости (Requires, Wants) могут снизить эффективность. Проверьте статус параллелизации через:

$ systemd-analyze dump | grep 'concurrent'

Если значение ниже 4–6 (количество доступных ядер памяти), внедрите ручное распараллеливание:

• Разбейте тяжелые скрипты на отдельные юниты с Before=/After=
• Используйте JOB_RUNNING и JOB_DEAD для отслеживания состояния

Финальная проверка и возможные ловушки

После внесения изменений повторно выполните systemd-analyze blame и сравнивайте результаты.

Ошибка "dependency cycle" — частый побочный эффект ручного переопределения зависимостей. Для отладки используйте:

$ systemd-analyze verify /etc/systemd/system/*.service

Учитывайте, что некоторые сервисы (например, systemd-udevd) критичны для аппаратной инициализации, и их модификация может привести к неработоспособности системы.

Результаты и рекомендации

На типичной рабочей станции с SSD удается достичь времени загрузки пользовательского пространства менее 4 секунд. Ключевые факторы успеха:

• Минимизированный initramfs с точно настроенными параметрами ожидания устройств
• Асинхронный запуск не связанных между собой сервисов (Docker, CUPS, VPN-клиенты)
• Отключение ненужного аппаратного мониторинга (например, smartd.service для NVMe-дисков)

Инструменты вроде systemd-boot вместо GRUB могут сократить время на этапе загрузчика, но требуют пересборки ESP-раздела. Для серверных развертываний рассмотрите возможность перевода критически важных сервисов в автозагрузку через socket activation.

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