Долгая загрузка системы 18.04

Изображение пользователя slknet.

Я понимаю, что уже неоднократно поднимался этот вопрос на этом форуме для различных дистрибутивов, но однозначного ответа, - в чем же основная причина неимоверно долгого запуска свеже установленной системы, я так и не увидел.
Стал разбираться самостоятельно.
Итак. Исходные данные.
Ноутбук Acer, на котором стояла 14.04 и параллельно Win 8.1. После выбора системы в Grub загрузка до появления приглашения происходила в обеих системах в пределах 30-40 сек. + после ввода пароля загрузка графического интерфейса - еще 20-30 сек. В общей сложности до появления рабочего стола проходило не более 1.30 мин.
Недели две назад поставил 18.04. Очень приятно удивила загрузка самого дистрибутива с флешки, но после полной установки я был сильно разочарован. Загрузка до приглашения составляла 1.30 - 2.00 мин. и примерно столько же после, до появления рабочего стола. В общей сложности полная загрузка системы проходила в пределаз 3-5 мин. При этом обратил внимание на примечательный нюанс. Загрузка с полностью выключенного состояния проходит значительно дольше, нежели при перезагрузке. Причем в винде загрузка никак не изменилась. Следовательно на железо не погрешишь.
Порывшись в нете на различных форумах нашел лишь, как ускорить загрузку ядра на несколько секунд, и как на несколько секунд ускорить загрузку путем отключения автозапуска неких сервисов (служб). Тем не менее, основной проблемы это не решило. Далее наткнулся на введенные в ситему новшества, в частности systemd, и стал подробно разбираться. Оказалось, что данный сервис обладает собственной журнализацией всего и вся, и именно эта журнализация занимает массу времени в процессе запуска. Причем с "холодного" запуска логи рисуются полностью на все процессы загрузки, а на перезагрузке, только на некоторые. Отсюда и разница во времени "холодного" запуска и перезагрузки. Вот и определился основной виновник неприлично долгой закрузки системы.

Теперь главное. Как я поступил в моем случае.
1.
Самое главное
В терминале: sudo journalctl --vacuum-size=5M
Далее в /etc/systemd/jurnald.conf выставил значение:
SystemMaxUse=5M
2.
Внес изменения в /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet rootfstype=ext4 libahci.ignore_sss=1 raid=noautodetect selinux=0 plymouth.enable=0 lpj=8779456"
GRUB_DISABLE_LINUX_UUID=true
Параметр lpj определяется индивидуально для каждой системы командой в терминале: dmesg | grep 'lpj='
Это позволило сократить время загрузки ядра в 2 раза (с 11 до 5 сек.)
3.
Отключил ненужные сервисы (службы):
sudo systemctl disable rsyslog
sudo systemctl disable cron
sudo systemctl disable ufw
sudo systemctl disable apport
sudo systemctl disable avahi-daemon
sudo systemctl disable apparmor
sudo systemctl disable mpd
Время загрузки сократилось еще примерно на 20-30%
4.
Так же я пришел к выводу, что поскольку корневой раздел проверяется на наличие ошибок в любом случае (а это время), то физический размер корневого раздела имеет значение и влияет на время загрузки.
Я уменьшил размер корня с 50Гб до 15Гб, а /home перенес на другой раздел.

Таким образом "холодный" запуск до появления рабочего стола получился в пределах 1.20-1.30 мин., а перезагрузка - в пределах 1-1.20 мин.

Интересно было бы узнать, какие у кого есть еще варианты.

0
jzyken - 30 Август, 2018 - 20:09
Изображение пользователя jzyken.

Что говорят:
systemd-analyze critical-chain
systemd-analyze blame
systemd-analyze plot >plot.svg
?

0
slknet - 30 Август, 2018 - 20:40
Изображение пользователя slknet.

Ну так на данный момент уже все в пределах нормы.[email protected]:~$ systemd-analyze
Startup finished in 4.957s (kernel) + 26.031s (userspace) = 30.988s
graphical.target reached after 26.025s in userspace

Но я хотел бы обратить внимание на то, что когда происходит совершенно не нормальная журнализация, а размеры самих журналов достаточно весомые, и на их обработку уходит масса времени, тогда процессы, которые ждут окончания журнализации себя самих со стороны systemd, неимоверно тормозят процессы, зависимые от них. А таких процессов достаточно много, несмотря на то, что происходит параллельное выполнение потоков загрузки. И при такой организации (без рихтовки и настройки самой jurnald) привычные формы анализа могут отображать сильно завышенные значения совершенно различных операций. Причем с каждым запуском совершенно разных. Как карта ляжет на параллельных потоках загрузки.
Однозначно завышенные результаты всегда показывал systemd-journal-flush.service, systemd-journald.service и systemd-tmpfiles-setup-dev.service. И надо было разобраться - почему, и как это исправить.
Я попытался разобраться.

А вот если вы посоветуете, как можно ускорить загрузку NetworkManager, то я буду весьма признателен.
Избавиться от него вообще предлагать не стоит, потому как это не вариант решения вопроса.

0
jzyken - 30 Август, 2018 - 20:51
Изображение пользователя jzyken.

Я понял, вы делитесь своими результатами борьбы с проблемой. Вот только для новичков напишите вначале, что бездумно выполнять приведённые команды не стоит.
Ну я тоже не раз замечал, что systemd-journal-flush.service много времени работает на жд. Что не очень понятно, почему запись ~800 строчек логов может занимать около 30 секунд даже на стареньких, медленных дисках...
Именно NetworkManager или может NetworkManager-wait-online ;)

0
slknet - 30 Август, 2018 - 21:04
Изображение пользователя slknet.

Вот только для новичков напишите вначале, что бездумно выполнять приведённые команды не стоит.Как раз именно новичкам я бы и рекомендовал выполнить все в точности, поскольку никаких негативных последствий приведенные мной команды и изменения не предполагают в принципе. Тем более, что в последствии, без особого труда, можно все вернуть к изначальному варианту без каких-либо потерь.
Именно NetworkManager или может NetworkManager-wait-online ;)Ну насколько я понимаю, это обе службы именно NetworkManager-а.
Не?
Вообще он мне показывает загрузку обеих служб в сумме примерно в 10 сек.

0
jzyken - 30 Август, 2018 - 22:26
Изображение пользователя jzyken.

1. 5мб для логов journald это мало. На Ubuntu 18.04 видел краем глаза, что туда спамит gnome и за пару дней может набежать полгигабайта...
2. GRUB_DISABLE_LINUX_UUID=true Подключит человек ещё диск (флеху?) и уже не запустится. Чёрный экран и белые буковки. Аааа
3. Просто disable мало что даст. Нужно маскировать. Но вот нужно ли? Apparmor нужен snap-у, mpd, avahi тоже могут быть нужны каким-то прикладным приложениям. A ufw? А cron?

NetworkManager.service запускает nm и настраивает сеть.
NetworkManager-wait-online.service ожидает пока сеть не станет доступной (что под этим nm подразумевает - не знаю, не читал) и потом "достигает" network-online.target. После чего уже запускаются сервисы желающие последнего.
Поэтому, зная, как эти сервисы на вашем пк работают, а они всё-равно запускаются и без network-online.target, потому как "Wants" а не "Requires", можно маскировать ожидание сети. И это приведёт к проблемам только в случае кривого сервиса, не умеющего реагировать на изменения сети. Но зато ускорит загрузку от пары до 30 секунд.
Естественно, при условии, что у вас нету монтирующегося из сети, например, /home... или ещё чего-то подобного.
Короче, к чему я это. Чем больше делаешь каких-то малопонятных изменений вычитанных из блогов, тем больше вероятность столкнуться в будущем с такими же малопонятными проблемами =)

0
slknet - 30 Август, 2018 - 22:44
Изображение пользователя slknet.

1. 5мб для логов journald это мало. На Ubuntu 18.04 видел краем глаза, что туда спамит gnome и за пару дней может набежать полгигабайта...Вы сами когда последний раз обращались к логам?!
Вот и я про то ж. Да и логи вам нужны (в случае чего) на ближайшие день-два. 5Мб - это примерно 48-50 тыс. строк в текстовом варианте, что примерно на два дня журнализации. Ну можно увеличить в два раза. И этого более чем достаточно.
2. GRUB_DISABLE_LINUX_UUID=true Подключит человек ещё диск (флеху?) и уже не запустится. Чёрный экран и белые буковки. АаааВот этого вообще не понял. Поясните, что вы хотели сказать?
У меня все конектится и запускается без проблем.
3. Просто disable мало что даст. Нужно маскировать. Но вот нужно ли?Маскировать не стоит, потому как может быть использовано самой системой. По-этому и disable, что позволяет убрать из автозагрузки и уменьшить время запуска. А после запуска система достаточно стабильна и шустра. Проблем пока не наблюдал.
Что касаемо служб, то это дело вкуса. Лично я отключил то, что написал. Система в стадии обкатки на рабочем ноуте. Пока проблем не испытываю. Думаю, что на ней и останусь. Проблемы буду решать по ходу поступления.

По поводу NetworkManager-а.
Так у вас есть конкретные действия по ускорению запуска перечисленных вами служб?

+1
jzyken - 30 Август, 2018 - 23:48
Изображение пользователя jzyken.

По поводу журнала не соглашусь. Вот только пару дней назад я заметил, что ядро у меня грузится целых 8 секунд и надо было посмотреть, это всегда так происходило или после какой-то определённой версии. Или после установки проприетарного драйвера nvidia. Сегодня вот рылся в /var/log/apt/history. Логи как и бекапы, в один момент могут очень пригодиться.

Вот этого вообще не понял. Поясните, что вы хотели сказать?
Допустим у вас что-то грузится с /dev/sda подключнного к SATA2. Вы подключаете новый диск в SATA1 и теперь он может стать /dev/sda, а предыдущий /dev/sdb. А вот UUID сохранится каким был.

Так у вас есть конкретные действия по ускорению запуска перечисленных вами служб? Кроме как замаскировать NetworkManager-wait-online.service нет. Но делать это понимая, зачем, как оно работает и на что может повлиять.

0
slknet - 31 Август, 2018 - 01:27
Изображение пользователя slknet.

По поводу журналов в целом с вами согласен, что это нужный инструмент. Только вот надобно найти оптимальный вариант. Решил поэкспериментировать пару дней с объемами журнализации systemd.
О результатах отпишусь.
Допустим у вас что-то грузится с /dev/sda подключнного к SATA2. Вы подключаете новый диск в SATA1 и теперь он может стать /dev/sda, а предыдущий /dev/sdb. А вот UUID сохранится каким был.Ну во-первых, если вы заметили, я писал про ноутбук. А для ноута этот пример неприемлем. Но даже если представить такую ситуацию на стационаре, то это не проблема вообще. Вопрос решается либо банальным перетыкиванием шлейфов HDD, либо редакцией /etc/fstab посредством fdisk и blkid. И опять же без каких-либо потерь.
Кроме как замаскировать NetworkManager-wait-online.service нет. Но делать это понимая, зачем, как оно работает и на что может повлиять.Ну опять же методом тыка. Попробую, отпишусь.

0
Boom - 31 Август, 2018 - 01:46
Изображение пользователя Boom.

Ядро новее 4.15?Пакет haveged стоит?Поставить sudo apt install haveged

0
slknet - 31 Август, 2018 - 09:55
Изображение пользователя slknet.

Ядро новее 4.15?[email protected]:~$ uname -a
Linux aaa-slknet 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Пакет haveged стоит?Нет.Поставить sudo apt install havegedЗачем?[email protected]:~$ cat /proc/sys/kernel/random/entropy_avail
3650
Как реально он может повлиять на скорость запуска?
У вас есть по этому поводу какой-либо опыт?

0
Boom - 31 Август, 2018 - 10:07
Изображение пользователя Boom.

Затем что помогло.

0
slknet - 31 Август, 2018 - 23:20
Изображение пользователя slknet.

Это в принципе ну никак не может повлиять на время загрузки системы, потому как способы генерирования случайных чисел и время, затраченное на запуск того или иного ПО, это примерно как соотношение "зеленого" к "вашему весу".
Но на всякий случай проверил.
ВЫВОД: Зря потратил время.

0
slknet - 31 Август, 2018 - 23:28
Изображение пользователя slknet.

Вы хоть суть своего предложения описать можете?
Как, ГСЧ может повлиять на время загрузки???!!!
Или просто тупо жмем кнопки (все подряд), а потом радуемся, что из тысячи нажатий пару прошло успешно?

Вы суть этого действа способны изложить?
Я со вниманием выслушаю.

0
slknet - 1 Сентябрь, 2018 - 00:21
Изображение пользователя slknet.

Теперь по сути поста.
Кроме как замаскировать NetworkManager-wait-online.service нет. Но делать это понимая, зачем, как оно работает и на что может повлиять.Отключил и наложил маску. Весь день работаю без проблем. Подключался по вай-фай - НОРМА. По USB модему - НОРМА. По шнурку - НОРМА.
Вывод: данную службу можно "погасить". Выиграл несколько сек. на загрузке.

Что касаемо объема журналов systemd. Еще тестирую. Ничего конкретного по поводу того, какой объем на сколько дней, пока не скажу. Но уже могу с уверенностью сказать, что значение SystemMaxUse=50M (при увеличении объема журналов до примерно этого значения), достаточно ощутимо сказывается на времени загрузки.
Пока значение в 10Мб позволяет мне иметь вот такие параметры загрузки:
Startup finished in 4.257s (kernel) + 22.217s (userspace) = 26.475s
graphical.target reached after 20.156s in userspace

P.S.
Забыл отметить, что еще дополнительно полностью снёс snap.

0
Boom - 1 Сентябрь, 2018 - 01:15
Изображение пользователя Boom.

Просто напросто всю вот эту лажу описанную вами здесь с долгой загрузкой,с нетворк мэнеджнром и снапом я исправил одним лишь пакетом, погуглив а не геройствовал целый день.

Догоняйте.Может ещё где 10 сек наскребёте.
Startup finished in 4.249s (kernel) + 11.423s (userspace) = 15.672s
graphical.target reached after 1.911s in userspace

0
slknet - 1 Сентябрь, 2018 - 12:16
Изображение пользователя slknet.

Плюсанул за активное желание помочь. Спасибо конечно, но...
Теперь по сути:
Просто напросто всю вот эту лажу описанную вами здесь с долгой загрузкой,с нетворк мэнеджнром и снапом я исправил одним лишь пакетом, погуглив а не геройствовал целый день.sudo apt install haveged
sudo systemctl enable haveged.service

Перезагрузился раз семь. Вот результат:
Startup finished in 4.346s (kernel) + 22.193s (userspace) = 26.540s
graphical.target reached after 20.069s in userspace

Вывод: положительного результата - 0

Ну и у кого здесь лажа?

0
slknet - 1 Сентябрь, 2018 - 12:13
Изображение пользователя slknet.

Кстати, а вы не могли бы показать свой systemd-analyze blame?
Интересно было бы посмотреть.

0
slknet - 2 Сентябрь, 2018 - 00:10
Изображение пользователя slknet.

Ну что, уважаемый Boom?!
Напукал и убежал?
Или может попробуем разобраться в сути вопроса?

0
slknet - 3 Сентябрь, 2018 - 11:14
Изображение пользователя slknet.

Установка и включение в автозагрузку haveged положительных результатов не принесло. Удалять не стал.
Объем журналов выставил в 50Мбв /etc/systemd/jurnald.conf
SystemMaxUse=50M
Продолжаю наблюдать.

Заметил, что через какое-то время запуск происходит значительно дольше. Значительное время уходит на apt-daily-upgrade.service
Погуглил: (https://zalinux.ru/?p=1592)

отключил:
sudo systemctl disable apt-daily-upgrade.timer
sudo systemctl disable apt-daily.timer

В /etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::Unattended-Upgrade "1";

все значения выставил в "0"
Пока на сегодня имею:Startup finished in 4.589s (kernel) + 21.545s (userspace) = 26.135s
graphical.target reached after 19.411s in userspace

0
slknet - 9 Сентябрь, 2018 - 22:24
Изображение пользователя slknet.

Обновился до 18.10. Плазма по умолчанию 5.13.
Проверил настройки и отключение того, о чем писал выше. Время загрузки увеличилось в 1,5-2 раза. Плазма время от времени серьезно тормозит. И это не смотря на то, что плазму рекламируют, как более быструю по сравнению с 5.12 и в плане загрузки, и в плане производительности. На первый взгляд это не так.
Глубоко копать не стал. Откатился обратно, как было.

0
Priestone - 10 Сентябрь, 2018 - 13:45
Изображение пользователя Priestone.

Обновляться, ИМХО, значит тащить косяки из предыдущих экспериментов/настроек/сторонних реп предыдущей версии дистрибутива (не ради же голой системы ставилось, верно?). Так что пробовать новую сборку надо ТОЛЬКО на чистую установку. И тогда статистика по времени загрузки, производительности и т.д. будет более-менее показательной.

0
slknet - 10 Сентябрь, 2018 - 20:37
Изображение пользователя slknet.

Не совсем согласен, но спорить не стану.
Дело случая и личного предпочтения.
А по поводу времени загрузки, ну так если было более менее нормально, а стало хуже, то наверное причины не в косяках, которых не было, а в обновленном ПО.
Не?

0
Гость - 21 Январь, 2019 - 10:05

Добрый день. Подскажите пожалуйста, чем можно исправить мою ситуацию.
У меня очень долго загружается ядро - 35 секунд. Потом всё остальное загружается всего 11 секунд.
У всех ядра загружаются быстрее.

Linux home 4.15.0-43-generic
Description: Ubuntu 18.04.1 LTS
Startup finished in 35.028s (kernel) + 11.267s (userspace) = 46.296s
graphical.target reached after 11.252s in userspace

0
Гость - 25 Январь, 2019 - 11:17

У меня был лаг в 30 секунд при загрузке. Связано было с тем, что я обновил 16.04 на 18.04 и перенес раздел на другой диск. В результате у меня "застрял" swap раздел и возникла проблема с ГСЧ. Только решив обе проблемы этот лаг исчез.

ГСЧ чинится так:
sudo apt install haveged
sudo systemctl enable haveged

swap так:
в файле: /etc/initramfs-tools/conf.d/resume
параметр RESUME=UUID={some-uuid} меняем на RESUME=none
обновляем: sudo update-initramfs -uk all

Я использовал диагностику через dmesg.
[ 3.832946] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
так же было в р-не 30-х секунд.
[ 4.381549] random: crng init done
в случае с лагом эта строка была не на 4-й секунде, а на 30-й.

Отправить комментарий

CAPTCHA на основе изображений
Введите цифры