Долгая загрузка системы 18.04
Я понимаю, что уже неоднократно поднимался этот вопрос на этом форуме для различных дистрибутивов, но однозначного ответа, - в чем же основная причина неимоверно долгого запуска свеже установленной системы, я так и не увидел.
Стал разбираться самостоятельно.
Итак. Исходные данные.
Ноутбук 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 мин.
Интересно было бы узнать, какие у кого есть еще варианты.
Что говорят:
systemd-analyze critical-chain
systemd-analyze blame
systemd-analyze plot >plot.svg
?
Ну так на данный момент уже все в пределах нормы.
Но я хотел бы обратить внимание на то, что когда происходит совершенно не нормальная журнализация, а размеры самих журналов достаточно весомые, и на их обработку уходит масса времени, тогда процессы, которые ждут окончания журнализации себя самих со стороны systemd, неимоверно тормозят процессы, зависимые от них. А таких процессов достаточно много, несмотря на то, что происходит параллельное выполнение потоков загрузки. И при такой организации (без рихтовки и настройки самой jurnald) привычные формы анализа могут отображать сильно завышенные значения совершенно различных операций. Причем с каждым запуском совершенно разных. Как карта ляжет на параллельных потоках загрузки.
Однозначно завышенные результаты всегда показывал systemd-journal-flush.service, systemd-journald.service и systemd-tmpfiles-setup-dev.service. И надо было разобраться - почему, и как это исправить.
Я попытался разобраться.
А вот если вы посоветуете, как можно ускорить загрузку NetworkManager, то я буду весьма признателен.
Избавиться от него вообще предлагать не стоит, потому как это не вариант решения вопроса.
Я понял, вы делитесь своими результатами борьбы с проблемой. Вот только для новичков напишите вначале, что бездумно выполнять приведённые команды не стоит.
Ну я тоже не раз замечал, что systemd-journal-flush.service много времени работает на жд. Что не очень понятно, почему запись ~800 строчек логов может занимать около 30 секунд даже на стареньких, медленных дисках...
Именно NetworkManager или может NetworkManager-wait-online ;)
Как раз именно новичкам я бы и рекомендовал выполнить все в точности, поскольку никаких негативных последствий приведенные мной команды и изменения не предполагают в принципе. Тем более, что в последствии, без особого труда, можно все вернуть к изначальному варианту без каких-либо потерь.
Ну насколько я понимаю, это обе службы именно NetworkManager-а.
Не?
Вообще он мне показывает загрузку обеих служб в сумме примерно в 10 сек.
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... или ещё чего-то подобного.
Короче, к чему я это. Чем больше делаешь каких-то малопонятных изменений вычитанных из блогов, тем больше вероятность столкнуться в будущем с такими же малопонятными проблемами =)
Вы сами когда последний раз обращались к логам?!
Вот и я про то ж. Да и логи вам нужны (в случае чего) на ближайшие день-два. 5Мб - это примерно 48-50 тыс. строк в текстовом варианте, что примерно на два дня журнализации. Ну можно увеличить в два раза. И этого более чем достаточно.
Вот этого вообще не понял. Поясните, что вы хотели сказать?
У меня все конектится и запускается без проблем.
Маскировать не стоит, потому как может быть использовано самой системой. По-этому и disable, что позволяет убрать из автозагрузки и уменьшить время запуска. А после запуска система достаточно стабильна и шустра. Проблем пока не наблюдал.
Что касаемо служб, то это дело вкуса. Лично я отключил то, что написал. Система в стадии обкатки на рабочем ноуте. Пока проблем не испытываю. Думаю, что на ней и останусь. Проблемы буду решать по ходу поступления.
По поводу NetworkManager-а.
Так у вас есть конкретные действия по ускорению запуска перечисленных вами служб?
По поводу журнала не соглашусь. Вот только пару дней назад я заметил, что ядро у меня грузится целых 8 секунд и надо было посмотреть, это всегда так происходило или после какой-то определённой версии. Или после установки проприетарного драйвера nvidia. Сегодня вот рылся в /var/log/apt/history. Логи как и бекапы, в один момент могут очень пригодиться.
Допустим у вас что-то грузится с /dev/sda подключнного к SATA2. Вы подключаете новый диск в SATA1 и теперь он может стать /dev/sda, а предыдущий /dev/sdb. А вот UUID сохранится каким был.
Кроме как замаскировать NetworkManager-wait-online.service нет. Но делать это понимая, зачем, как оно работает и на что может повлиять.
По поводу журналов в целом с вами согласен, что это нужный инструмент. Только вот надобно найти оптимальный вариант. Решил поэкспериментировать пару дней с объемами журнализации systemd.
О результатах отпишусь.
Ну во-первых, если вы заметили, я писал про ноутбук. А для ноута этот пример неприемлем. Но даже если представить такую ситуацию на стационаре, то это не проблема вообще. Вопрос решается либо банальным перетыкиванием шлейфов HDD, либо редакцией /etc/fstab посредством fdisk и blkid. И опять же без каких-либо потерь.
Ну опять же методом тыка. Попробую, отпишусь.
Ядро новее 4.15?Пакет haveged стоит?Поставить sudo apt install haveged
aaa@aaa-slknet:~$ 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
aaa@aaa-slknet:~$ cat /proc/sys/kernel/random/entropy_availКак реально он может повлиять на скорость запуска?3650
У вас есть по этому поводу какой-либо опыт?
Затем что помогло.
Это в принципе ну никак не может повлиять на время загрузки системы, потому как способы генерирования случайных чисел и время, затраченное на запуск того или иного ПО, это примерно как соотношение "зеленого" к "вашему весу".
Но на всякий случай проверил.
ВЫВОД: Зря потратил время.
https://www.linux.org.ru/forum/desktop/14261271
Вы хоть суть своего предложения описать можете?
Как, ГСЧ может повлиять на время загрузки???!!!
Или просто тупо жмем кнопки (все подряд), а потом радуемся, что из тысячи нажатий пару прошло успешно?
Вы суть этого действа способны изложить?
Я со вниманием выслушаю.
Теперь по сути поста.
Отключил и наложил маску. Весь день работаю без проблем. Подключался по вай-фай - НОРМА. По USB модему - НОРМА. По шнурку - НОРМА.
Вывод: данную службу можно "погасить". Выиграл несколько сек. на загрузке.
Что касаемо объема журналов systemd. Еще тестирую. Ничего конкретного по поводу того, какой объем на сколько дней, пока не скажу. Но уже могу с уверенностью сказать, что значение SystemMaxUse=50M (при увеличении объема журналов до примерно этого значения), достаточно ощутимо сказывается на времени загрузки.
Пока значение в 10Мб позволяет мне иметь вот такие параметры загрузки:
Startup finished in 4.257s (kernel) + 22.217s (userspace) = 26.475sgraphical.target reached after 20.156s in userspace
P.S.
Забыл отметить, что еще дополнительно полностью снёс snap.
Просто напросто всю вот эту лажу описанную вами здесь с долгой загрузкой,с нетворк мэнеджнром и снапом я исправил одним лишь пакетом, погуглив а не геройствовал целый день.
Догоняйте.Может ещё где 10 сек наскребёте.
Плюсанул за активное желание помочь. Спасибо конечно, но...
Теперь по сути:
sudo apt install haveged
sudo systemctl enable haveged.service
Перезагрузился раз семь. Вот результат:
Startup finished in 4.346s (kernel) + 22.193s (userspace) = 26.540sgraphical.target reached after 20.069s in userspace
Вывод: положительного результата - 0
Ну и у кого здесь лажа?
Кстати, а вы не могли бы показать свой systemd-analyze blame?
Интересно было бы посмотреть.
Ну что, уважаемый Boom?!
Напукал и убежал?
Или может попробуем разобраться в сути вопроса?
Обновился до 18.10. Плазма по умолчанию 5.13.
Проверил настройки и отключение того, о чем писал выше. Время загрузки увеличилось в 1,5-2 раза. Плазма время от времени серьезно тормозит. И это не смотря на то, что плазму рекламируют, как более быструю по сравнению с 5.12 и в плане загрузки, и в плане производительности. На первый взгляд это не так.
Глубоко копать не стал. Откатился обратно, как было.
Обновляться, ИМХО, значит тащить косяки из предыдущих экспериментов/настроек/сторонних реп предыдущей версии дистрибутива (не ради же голой системы ставилось, верно?). Так что пробовать новую сборку надо ТОЛЬКО на чистую установку. И тогда статистика по времени загрузки, производительности и т.д. будет более-менее показательной.
Не совсем согласен, но спорить не стану.
Дело случая и личного предпочтения.
А по поводу времени загрузки, ну так если было более менее нормально, а стало хуже, то наверное причины не в косяках, которых не было, а в обновленном ПО.
Не?
Добрый день. Подскажите пожалуйста, чем можно исправить мою ситуацию.
У меня очень долго загружается ядро - 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
У меня был лаг в 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-й.
Отправить комментарий