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

Jump to content

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

5 languages

- English
- Español
- Français
- 日本語
- Português

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

Ссылки по теме

- Увеличение производительности
- Тихая загрузка
- Демоны
- Kexec

Улучшение производительности загрузки системы уменьшает время ожидания загрузки, а также служит способом изучения взаимодействия определённых системных файлов и скриптов друг с другом. В этой статье сделана попытка собрать воедино методы ускорения загрузки системы 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, это сэкономит ещё больше времени.

## Ждущий режим

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

Category:

- Boot process (Русский)