Команда скорости загрузки линукс

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

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

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

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

С помощью systemd-analyze

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

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

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

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

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

$ 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:

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

Для отключения добавьте параметр ядра 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 , который mlocate по умолчанию игнорирует. В зависимости от системы, ускорение от отложенного монтирования /home может составлять около секунды-двух, так что, возможно, это не стоит того.
• Если система установлена в подтом btrfs (то есть корневой каталог / сам по себе является подтомом), а /home находится на отдельной файловой системе, вы можете захотеть предотвратить создание подтома /home . Замаскируйте tmpfiles-настройку home.conf : ln -s /dev/null /etc/tmpfiles.d/home.conf .

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

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

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

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

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

Ждущий режим

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

Источник

Команда скорости загрузки линукс

В более ранних версиях Linux Mint вы можете установить и использовать загрузочный файл для анализа времени загрузки. Если у вас возникли проблемы с Linux Mint 18 и загрузка (внезапно) увеличилась, вы можете использовать различные команды для получения информации, которая может помочь найти причину. Ниже перечислены команды, которые я нашел полезными.

Первая команда получает информацию о том, сколько времени было потрачено на ядро ​​Linux во время загрузки и сколько в пользовательском пространства
systemd-analyze time
и далее по списку
Команда получает информацию о том, сколько времени каждый процессор взял для инициализации во время загрузки.
systemd-analyze —no-pager blame
Команда создает файл plot.svg с загрузочной диаграммой. График появится в домашней папке.
systemd-analyze plot > plot.svg
Команда показывает все сообщения об ошибках из текущей загрузки.
journalctl —no-pager -b -p3
Команда показывает какие процессы не запустились.
systemctl —no-pager —state=failed

Наконец, есть вероятность, что проблема может быть связана с жесткими дисками

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,UUID cat /etc/fstab

Seisan Сообщения: 191 Зарегистрирован: 18 ноя 2016, 15:35 Решено: 3 Откуда: Средний Урал Благодарил (а): 41 раз Поблагодарили: 121 раз Контактная информация:

Анализируем время загрузки Linux Mint 18

После установки LM-18.3 XFCE x64 наблюдал такое явление: грузилась система около 2-x минут по сравнению с LM-17.3 XFCE, которая загружалась махом. «Вылечил» банально для своего железа — поставил Swap в начало диска

Linux Mint 18.3 Xfce , Kernel: 4.15.0-54-generic x86_64 , Memory: 8Гб , Graphics NVIDIA GK208B GeForce GT 710 , браузер Palemoon

Zarya.Dima Сообщения: 19 Зарегистрирован: 03 май 2018, 18:13 Решено: 1 Откуда: KAZ /=/ RUSS Благодарил (а): 10 раз Контактная информация:

Анализируем время загрузки Linux Mint 18

dimas@ASUS ~ $ systemd-analyze time Startup finished in 2.783s (firmware) + 2.632s (loader) + 4.562s (kernel) + 3.058s (userspace) = 13.036s 

В Общем как то так, SSD, 8gb Ram. i7-3537. Swap кинул в самый конец диска может для HDD имеет значение где Swap висит.

Источник

Команда скорости загрузки линукс

Чтобы ускорить загрузку системы линукс, необходимо сначала провести анализ. В этом нам поможет systemd-analyze.

Для начала мы можем посмотреть время загрузки операционной системы. Введем следующую команду:

Вывод у меня получился такой:

Startup finished in 2.551s (kernel) + 5.787s (userspace) = 8.338s
graphical.target reached after 5.765s in userspace

Из него мы видим, что ядро загрузилось за 2.551 секунды, а все остальное за 5.787. Итого около 8 секунд грузилась вся система. Графический интерфейс стал доступен через 5.765 секунды.

Дальше мы можем посмотреть, что же больше всего задерживает загрузку:

# systemd-analyze blame | head -n 10

4.279s apparmor.service
1.044s man-db.service
951ms apt-daily-upgrade.service
834ms apt-daily.service
790ms logrotate.service
619ms upower.service
573ms systemd-logind.service
461ms dev-sda2.device
180ms udisks2.service
158ms systemd-timesyncd.service

Видим, что в ТОП-3 у нас входят: apparmor.service, man-db.service, apt-daily-upgrade.service… Надо над этим подумать на досуге 🙂

И на десерт – графическая карта анализа загрузки Linux:

# systemd-analyze plot > boot_analysis.svg

Открываем файл boot_analysis.svg (например, через Gwenview) и видим то, что на скриншоте.

Теперь-то точно ни один процесс загрузки не останется незамеченым! Удачи в поисках и оптимизации загрузки Вашей ОС!

Источник