Improving performance (Русский)/Boot process (Русский)

From ArchWiki
Состояние перевода: На этой странице представлен перевод статьи Improving performance/Boot process. Дата последней синхронизации: 15 декабря 2022. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Улучшение производительности загрузки системы уменьшает время ожидания загрузки, а также служит способом изучения взаимодействия определённых системных файлов и скриптов друг с другом. В этой статье сделана попытка собрать воедино методы ускорения загрузки системы Arch Linux.

Анализ процесса загрузки

С помощью systemd-analyze

В состав systemd входит инструмент systemd-analyze, который можно использовать для просмотра информации о времени загрузки, в том числе svg-график с отображением юнитов, ожидающих запуска своих зависимостей. Вы можете увидеть, какие юниты вызывают замедление процесса загрузки, и попытаться оптимизировать их запуск.

Чтобы узнать, сколько времени было потрачено в пространстве ядра и пространстве пользователя при загрузке, просто используйте:

$ systemd-analyze
Совет: Если загрузка выполняется через UEFI и используется загрузчик, который реализует systemd Boot Loader Interface (на данный момент его реализуют только systemd-boot и GRUB), systemd-analyze сможет дополнительно показать, сколько времени было потрачено на работу прошивки EFI и самого́ загрузчика.

Просмотр списка запущенных юнитов, отсортированного по времени, которое потребовалось каждому из них для запуска:

$ systemd-analyze blame

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

$ systemd-analyze critical-chain

Также можно создать создать SVG-файл, который демонстрирует процесс загрузки в графическом виде, подобно Bootchart:

$ systemd-analyze plot > plot.svg

Смотрите systemd-analyze(1) для более подробной информации.

С помощью bootchart2

Также можно использовать Bootchart2 для визуализации процесса загрузки.

Использование хука systemd

По умолчанию в конфигурации mkinitcpio для сборки initramfs используются хуки base и udev. Для более быстрой загрузки их можно заменить на systemd.

Смотрите mkinitcpio (Русский)#Доступные хуки для более подробной информации. Также смотрите fsck (Русский)#Проверка при загрузке в случае замены хука fsck.

Компиляция собственного ядра

Компиляция своего ядра может сократить время загрузки и использование памяти, хотя со стандартизацией 64-битной архитектуры и модульной природой ядра Linux улучшение может оказаться не таким значительным. Смотрите Ядро#Компиляция для более подробной информации.

Initramfs

Самый простой способ уменьшить размер initramfs — добавить хук autodetect в настройках mkinitcpio. Более сложные методы уменьшения размера описаны в статье Minimal initramfs.

В зависимости от вашего оборудования (процессора и скорости хранилища), использование lz4 вместо используемого по умолчанию алгоритма сжатия zstd может оказаться быстрее, поскольку более высокая скорость декомпрессии при загрузке обычно компенсирует немного больший размер initramfs, который приходится считывать с диска. Смотрите раздел mkinitcpio (Русский)#COMPRESSION.

Выбор оптимального способа запуска служб

Одной из центральных особенностей systemd является активация через D-Bus и сокеты. Это предпочтительно в большинстве случаев, поскольку позволяет службам запускаться только при первом обращении к ним, что, как правило, хорошо (например, включение службы cups.service во время загрузки обычно не особо полезно для настольных систем, вместо него лучше включить cups.socket, который будет запускать службу, только когда потребуется что-то распечатать).

Однако если вы точно знаете, что какая-то служба (например, upower) всегда будет запускаться во время загрузки, то общее время загрузки можно уменьшить, запустив её как можно раньше. Для этого можно включить службу, например upower.service (если файл службы настроен для этого, что в большинстве случаев так и есть).

Это заставит systemd запустить UPower как можно раньше, не вызывая гонок с активацией сокета или D-Bus.

Последовательная раскрутка дисков

Некоторые диски поддерживают последовательную раскрутку (staggered spin-up): ОС проверяет интерфейсы ATA последовательно, что позволяет раскручивать диски по одному и таким образом снижать пиковое энергопотребление. Это замедляет скорость загрузки, а на большинстве домашних компьютеров вообще не даёт никаких преимуществ, поскольку диски уже раскручиваются сразу после включения питания. Чтобы проверить, используется ли SSS:

# dmesg | grep SSS

Если не используется, то эта команда ничего не выведет.

Для отключения добавьте параметр ядра libahci.ignore_sss=1.

Монтирование файловых систем

Благодаря хуку fsck в mkinitcpio можно избежать дорогостоящего перемонтирования корневого раздела, изменив ro на rw в параметрах ядра: опции монтирования можно задать через rootflags=rw,другие_опции. Запись должна быть удалена из файла /etc/fstab, иначе служба systemd-remount-fs.service будет продолжать попытки применения этих настроек. В качестве альтернативы можно попытаться замаскировать этот юнит.

Если в качестве корневой файловой системы используется Btrfs, то нет необходимости в выполнении fsck при каждой загрузке, как в других файловых системах. В этом случае можно удалить хук fsck. Вы также можете замаскировать службу systemd-fsck-root.service или запретить ей выполнять проверку корневой файловой системы с помощью параметра ядра fsck.mode=skip. Без fsck systemd всё равно будет выполнять проверку всех соответствующих файловых систем через systemd-fsck@.service.

Из /etc/fstab можно удалить записи для тех точек монтирования, которые systemd монтирует сам с использованием своих юнитов (список таких юнитов можно посмотреть с помощью команды pacman -Ql systemd | grep '\.mount$'). Например, нередко пользователи по старой привычке добавляют запись для монтирования /tmp, как делали во времена sysvinit, но сегодня в этом нет необходимости, так как systemd-юнит tmp.mount уже позаботился об этом. Следовательно, такую запись можно смело удалить.

Другие файловые системы, такие как /home или системный раздел EFI, могут быть смонтированы с помощью отредактированных mount-юнитов. Добавление noauto,x-systemd.automount к опциям монтирования будет буферизировать весь доступ к этому разделу, а также будет выполнять проверку и монтировать его в момент первого обращения, таким образом уменьшая количество файловых систем, которые нужно проверять/монтировать в процессе загрузки.

Примечание:
  • Это изменит тип файловой системы /home на autofs, который locate по умолчанию игнорирует. В зависимости от системы, ускорение от отложенного монтирования /home может составлять около секунды-двух, так что, возможно, это не стоит того.
  • Если система установлена в подтом btrfs (то есть корневой каталог / сам по себе является подтомом), а /home находится на отдельной файловой системе, вы можете захотеть предотвратить создание подтома /home. Замаскируйте tmpfiles-настройку home.conf: ln -s /dev/null /etc/tmpfiles.d/home.conf.

Уменьшение вывода во время загрузки

На некоторых системах, особенно с SSD, узким местом процесса загрузки может оказаться медленный TTY, поэтому меньший объём выводимого в консоль текста означает более быструю загрузку. Смотрите статью Тихая загрузка для более подробной информации.

Изменение загрузчика

Изменение загрузчика (например, на более простой, такой как systemd-boot), может сэкономить несколько секунд.

Если есть возможность использовать EFISTUB, это сэкономит ещё больше времени.

Ждущий режим

Лучший способ сократить время включения системы — не выключать её вообще. Попробуйте вместо выключения использовать ждущий режим.