LINUX.ORG.RU

Долгая загрузка Ubuntu

 


0

2

Добрый день. Недавно поставил Ubuntu и он неоправданно долго грузиться.

Результат команды systemd-analyze time:

Startup finished in 2.660s (kernel) + 1min 52.195s (userspace) = 1min 54.856s graphical.target reached after 1min 52.154s in userspace

Результат команды systemd-analyze blame:

1min 43.809s plymouth-quit-wait.service
         11.058s gdm.service
          5.718s snapd.service
          4.770s networkd-dispatcher.service
          4.019s NetworkManager-wait-online.service
          3.953s dev-sdb5.device
          3.839s ModemManager.service
          3.381s udisks2.service
          2.951s e2scrub_reap.service
          2.802s accounts-daemon.service
          2.252s NetworkManager.service
          1.884s grub-initrd-fallback.service
          1.694s systemd-logind.service
          1.687s thermald.service
          1.652s rsyslog.service
          1.648s grub-common.service
          1.644s wpa_supplicant.service
          1.402s dev-loop2.device
          1.357s dev-loop8.device
          1.326s dev-loop6.device
          1.320s dev-loop0.device
          1.317s dev-loop5.device
          1.258s apport.service
          1.258s bluetooth.service
          1.225s dev-loop3.device
          1.181s systemd-journal-flush.service
           986ms dev-loop4.device
           969ms systemd-resolved.service
           888ms fwupd.service
           857ms polkit.service
           848ms gpu-manager.service
           840ms dev-loop7.device
           797ms dev-loop1.device
           673ms pppd-dns.service
           566ms systemd-udevd.service
           539ms upower.service
           461ms apparmor.service
           391ms plymouth-start.service
           312ms systemd-sysctl.service
           280ms systemd-modules-load.service
           279ms systemd-journald.service
           235ms switcheroo-control.service
           211ms systemd-sysusers.service
           211ms snap-core-7917.mount
           206ms systemd-fsck@dev-disk-by\x2duuid-f128339a\x2d1ea9\x2d4b24\x2dbb
           206ms systemd-tmpfiles-setup.service
           193ms snap-gnome\x2d3\x2d28\x2d1804-71.mount
           189ms user@124.service
           188ms systemd-timesyncd.service
           185ms systemd-random-seed.service
           183ms snap-gnome\x2dcalculator-501.mount
           171ms snap-core18-1223.mount
           162ms snap-gnome\x2dcharacters-359.mount
           158ms keyboard-setup.service
           152ms systemd-tmpfiles-setup-dev.service
           151ms snap-gtk\x2dcommon\x2dthemes-1353.mount
           142ms snap-gnome\x2dlogs-81.mount
           125ms colord.service
           123ms snap-gnome\x2dcharacters-317.mount
           114ms systemd-remount-fs.service
           112ms dev-disk-by\x2duuid-33722b57\x2d272b\x2d4ce7\x2d9853\x2df6e9b85
           104ms snap-gnome\x2dcalculator-536.mount
            99ms systemd-udev-trigger.service
            89ms kmod-static-nodes.service
            79ms systemd-tmpfiles-clean.service
            69ms systemd-update-utmp.service
            62ms bolt.service
            60ms kerneloops.service
            58ms plymouth-read-write.service
            56ms rtkit-daemon.service
            52ms systemd-rfkill.service
            47ms openvpn.service
            45ms ufw.service
            45ms user@1000.service
            39ms home.mount
            35ms dev-hugepages.mount
            34ms sys-kernel-debug.mount
            34ms dev-mqueue.mount
            27ms console-setup.service
            26ms setvtrgb.service
            25ms snapd.seeded.service
            19ms systemd-user-sessions.service
            16ms user-runtime-dir@124.service
            10ms snapd.socket
             8ms user-runtime-dir@1000.service
             5ms systemd-update-utmp-runlevel.service
             4ms avahi-daemon.service
             1ms sys-fs-fuse-connections.mount
             1ms sys-kernel-config.mount

Результат команды lsblk:

loop0    7:0    0   4,2M  1 loop /snap/gnome-calculator/536
loop1    7:1    0   956K  1 loop /snap/gnome-logs/81
loop2    7:2    0  14,8M  1 loop /snap/gnome-characters/317
loop3    7:3    0  44,2M  1 loop /snap/gtk-common-themes/1353
loop4    7:4    0  54,5M  1 loop /snap/core18/1223
loop5    7:5    0  14,8M  1 loop /snap/gnome-characters/359
loop6    7:6    0   4,2M  1 loop /snap/gnome-calculator/501
loop7    7:7    0 149,9M  1 loop /snap/gnome-3-28-1804/71
loop8    7:8    0  89,1M  1 loop /snap/core/7917
sda      8:0    0 931,5G  0 disk 
├─sda1   8:1    0   579M  0 part 
├─sda2   8:2    0  99,4G  0 part 
└─sda3   8:3    0 831,5G  0 part 
sdb      8:16   0   1,8T  0 disk 
├─sdb1   8:17   0  30,5G  0 part [SWAP]
├─sdb2   8:18   0     1K  0 part 
├─sdb5   8:21   0  47,7G  0 part /
└─sdb6   8:22   0   1,8T  0 part /home 

Ответ на: комментарий от Vsevolod-linuxoid

К удаленному посту про системку.

Материнка: Asus ROG Crosshair VIII Hero (Wi-Fi) Проц: AMD Ryzen 7 3800X Оператива: Skill TridentZ 3200 4x8 Видео: AMD Radeon RX 5700 XT SSD: Samsung SSD 860 EVO 1TB (Windows) HDD: TOSHIBA DT01ACA200 (Ubuntu)

Flax187 ()
Ответ на: комментарий от Deleted

Понимаю, но тут еще и ручник подняли как будто. Позже лог ошибок могу скинуть.

Flax187 ()
Ответ на: комментарий от Deleted
окт 22 17:38:37 Root-System kernel: ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000007) is beyond end of object (length 0x6) (20190703/exoparg2-393)
окт 22 17:38:37 Root-System kernel: ACPI Error: Aborting method \_SB.PCI0.BXBR.BYUP.BYD8.XHC1.RHUB.PRT6._PLD due to previous error (AE_AML_PACKAGE_LIMIT) (20190703/psparse-529)
окт 22 17:38:39 Root-System kernel: amdgpu 0000:0b:00.0: Failed to load gpu_info firmware "amdgpu/navi10_gpu_info.bin"
окт 22 17:38:39 Root-System kernel: amdgpu 0000:0b:00.0: Fatal error during GPU init
окт 22 17:38:44 Root-System kernel: ccp 0000:0d:00.1: sev command 0x4 timed out, disabling PSP 
окт 22 17:38:44 Root-System kernel: ccp 0000:0d:00.1: SEV: failed to get status. Error: 0x0
окт 22 17:38:44 Root-System bluetoothd[1067]: Failed to set mode: Blocked through rfkill (0x12)
окт 22 17:38:57 Root-System systemd[1429]: Failed to start GNOME Shell on Wayland.
окт 22 14:40:32 Root-System bluetoothd[1067]: Failed to set mode: Blocked through rfkill (0x12)
окт 22 14:40:41 Root-System gdm-password][1950]: gkr-pam: unable to locate daemon control file
окт 22 14:40:44 Root-System bluetoothd[1067]: Failed to set mode: Blocked through rfkill (0x12)
Flax187 ()
Ответ на: комментарий от Vsevolod-linuxoid

Вообще-то помогает зачастую.

Вот-вот. Если не избавиться от тормоза, то хотябы увидеть, что там за этим плимутом минуту с лишним делается.

Dementy ★★ ()
Ответ на: комментарий от Dementy

Пока скину результат systemd-analyze critical chain:

graphical.target @1min 52.267s
└─multi-user.target @1min 52.267s
  └─kerneloops.service @15.639s +57ms
    └─network-online.target @15.626s
      └─NetworkManager-wait-online.service @8.928s +6.698s
        └─NetworkManager.service @6.459s +2.468s
          └─dbus.service @6.456s
            └─basic.target @6.456s
              └─sockets.target @6.456s
                └─snapd.socket @6.454s +1ms
                  └─sysinit.target @6.418s
                    └─apparmor.service @5.928s +489ms
                      └─local-fs.target @5.926s
                        └─run-user-124.mount @19.727s
                          └─swap.target @5.717s
                            └─dev-disk-by\x2duuid-33722b57\x2d272b\x2d4ce7\x2d9853\x2df6e9b8570ea2.swap @5.626s +90ms
                              └─dev-disk-by\x2duuid-33722b57\x2d272b\x2d4ce7\x2d9853\x2df6e9b8570ea2.device @5.625s

Flax187 ()
Ответ на: комментарий от Flax187

Ладно, сорян, не уточнил.

Если в терминале написа́ть

systemd-analyze plot > чтонибудь.svf

то в /home нарисуется файл чтонибудь.svf. Это картинка, наглядно и подробно показывающая загрузку.

Dementy ★★ ()
Ответ на: комментарий от Flax187

Плимут убирать пробовать.

И вообще. Зачем 19.10? С RTS нормальную работу не обещали.

Dementy ★★ ()

ДаЙте скрин где тормозит. Скрин загрузки.

Bootmen ★☆☆ ()
Последнее исправление: Bootmen (всего исправлений: 1)
Ответ на: комментарий от Flax187

А для жсткого 1-2 минуты это норма. Особенно если какой нибудь интеллектуальный системд распаралелит запуск как следует.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от Flax187

Radeon RX 5700

Это который из новых? А сколько занимает инициация видеодрайвера? Я хз как выпытать это из убунты, но нормальные дистры вроде дебиана и генту на моём ноуте с radeon HD8450m ждут около 30 секунд инициацию видеокарты. Возможно для новых RX драйвер тоже тугой.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от Flax187

Failed to start GNOME Shell on Wayland.

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

kirill_rrr ★★★★★ ()
Ответ на: комментарий от kirill_rrr

А для жесткого 1-2 минуты это норма.

Это если система на жестком от того, что всё старое и слабое. А у ТС нормальные такие железяки.

Я не так давно сменил HDD на SSD и еще не достаточно тщательно забыл, что система у меня грузилась секунд двадцать.

Dementy ★★ ()
Ответ на: комментарий от kirill_rrr

А вот про прогрузку видеодров и заики с Гномом и Wayland - вот это, похоже, и есть причина. Плимут, кстати, какие дрова хочет, чтобы показаться? MESA какая-нибудь? Вот, пока она влезет, потом пока вылезет, пока другие дрова загрузятся...

Dementy ★★ ()
Ответ на: комментарий от Dementy

Харды разные бывают. У кого то 20, у кого то 3 минуты. Полутерабайт 5600 оборотов времёт коре2+3 года как раз на 1,5 минуты выходит.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от kirill_rrr

Так он же сказал, что TOSHIBA DT01ACA200. А вот у меня как раз на ST320LM001 HN-M320MBB (лет пять ему, емнип) система была.

Еще вот эта Убунта 19.10... Ну, имеет она право глючить и томозить по ситуации. Я вот 17.10 попробовал чуток и от RTS для использования отказался.

Dementy ★★ ()
Ответ на: комментарий от Dementy

Что странно, для одного из моих ноутбучных дисков, toshiba mq01abd100, среднее время чтения заявлено 12мс против 8,5, а латентность такая же. Т.е. тут не ракета какая нибудь.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от kirill_rrr

100-120 ioops

- это, конечно же, совсем мрачно. Но это же для 7200 об/мин в совсем издевательских условиях, когда ввод и вывод пытается лезть одновременно, обслуживается чисто по принципу FIFO, и при этом всё очень фрагментировано. При загрузке системы идет почти исключительно чтение, mq-deadline подпрягается, вроде как, вместе с ядром. Данные при установке системы фрагментировались мало. Хотя тут ТС тоже умолчал, в каком виде был HDD перед установкой на него системы.

Dementy ★★ ()
Ответ на: комментарий от Dementy

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

kirill_rrr ★★★★★ ()
Ответ на: комментарий от kirill_rrr

паралельный запуск кучи приложений это и есть тот саммый, мрачный сценарий.

ИМХО, по мрачности это что-то среднее между совсем бардаком и считыванием длинной непрерывной колбасы.

Насчёт шедулера не уверен что там задействуется что то, отличное от стандартного.

В Убунтах нынче mq-deadline дефолтом или можно переключить на none. Планировщик - он-то в ядре, но на каком моменте загрузки он включается?..

А вот буквально в соседней теме у человека Дебиан за полминуты с HDD грузится.

А ТС что-то пропал. Так что, что там в этом конкретном случае, похоже уже и не важно.

Dementy ★★ ()
Ответ на: комментарий от Dementy

но на каком моменте загрузки он включается

Очень рано. Где то в процессе инициализации блочного устройства.

mq-deadline

Сейчас что стандарт? cfq? bfq? Дедлайн кажется всегда уступает им в производительности, а по отзывчивости почти никогда их не превосходит. Антиципатори когда то был интересен для снижения нагрузки на диск, но дедлайн очень быстро слил этой парочке и стал историей.

Любопытно, нафига убунтоды откопали стюардессу и начали её патчить.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от kirill_rrr

Сейчас что стандарт?

В Убунтах-то? Вот что↓

dementy@RocksteR:~$ cat /sys/class/block/sd*/queue/scheduler
[mq-deadline] none
[mq-deadline] none
[mq-deadline] none
Это как пятое ядро стало. До того cfq был дефолтом. Ну и, говорят же, что deadline и mq-deadline - две большие разницы. mq-* - это, типа, молодёжно.

От себя добавлю, что да, с mq-deadline хорошо. Я когда-то начитался, что в SSD свой планировщик, который со своей железкой лучше всех знаком, и системный планировщик не нужен. Когда увидел возможность отключить планировщик вообще, радостно ею воспользовался. Оказалось, зря. Похоже, со стороны ОС нужен свой планировщик, а со стороны устройства - свой.

Dementy ★★ ()
Ответ на: комментарий от Dementy

Ну, убунта странная. И ядро у них странное (в ванильном вообще нет никакого mq-deadline). В своё время я сравнивал ядро дебиана и ядро убунту, основанной на том же релизе дебиана. В производительности разницы не было, всё железо работало на обоих ядрах, но дебовское ядро оставляло на 20М больше памяти доступной.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от kirill_rrr

ядро дебиана и ядро убунту

Кстати, а какое ядро нынче кладут в Дебиан? Вот, Убунту LTS сейчас работает на 5.0.0-32. В RTS новые ядра могут прилетать до их официального релиза.

убунта странная

Дебиан тоже веселый старикашка:). Вполне может на 4.x.x работать.

Dementy ★★ ()
Ответ на: комментарий от kirill_rrr

Увидело свет ядро Linux 5.0

Увеличение цифры мажорной версии до 5 не означает каких-то грандиозных изменений

Механизм blk-mq с многоуровневой системой очередей запросов стал основным для блочных устройств. Весь не-mq код удалён.

Ну, типа, мелочь.

Dementy ★★ ()
Ответ на: комментарий от Dementy

Что то странное и непонятное. Но система очередей запросов одноуровневая тольуо в шедулере noop.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от Dementy

И в первом же в гугле обзоре mq- планировщики слили на hdd и отыграли жалкие проценты у noop на ssd.

Я использовал bfq и cfq на pf-sources 4.4 в генту, разницы было ноль (ssd в основном. И разница в пределах погрешности подтверждается этим тестом). Но в итоге вся свистопляска с -pf у меня кончилась тем, что я внезапно обнаружил 30% падения производительности в какой то задаче, не помню какой.

Весь не-mq код удалён

Кажется жопа подкралась незаметно. Потому что выходит что это оптимизировано для очень быстрых ssd на многоядерных серверах, а для hdd будут тормоза при росте нагрузки на цпу и потреблении памяти.

Вся прелесть нововведения сводится к тому, что старые планировщики поровну делили время между чтением и записью и при интенсивной записи на твердотельную память с непредсказуемой задержкой записи система захлёбывалась. Здесь же приоритет отдали чтению. Многопоточность на десктопах в принципе ни при чём.

kirill_rrr ★★★★★ ()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

Блин. Я прочитал вслух Fair Queueing. Да неужели?!! А с другой стороны, сначала Линуса на работе не материться попросили, потом из комментариев матюки чистить стали, потом вот.

А если серьезно... Возможно, предположили, что HDD - это прошлое. А где на них большие и важные файловища - там RAIDы, так что и там mq- лучше будет.

Опять же. Не хочу УМВРизмом заниматься, но лично я за mq-deadline плохого не заметил. Интерсно, конечно, Kyber пощупать, но его в ядро класть не спешат.

Dementy ★★ ()
Ответ на: комментарий от Dementy

deadline, что mq что старый, не совсем стандартны. Они должны повысить отзывчивость при многопоточном и хатоичном доступе. cfq и bfq дают более хорошие результаты в среднем. Странно что на убунте bfq вообще не оказалось.

Да, кстати... выпиливать то зачем? cfq оптимален для hdd? ну так давайте его для них и включать.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от Flax187

Asus ROG Crosshair VIII Hero (Wi-Fi) не могу найти в интернетах отзывы о работе в линуксах. есть проблемы?

vvviperrr ★★★★★ ()
Ответ на: комментарий от anti_win

Причем, большую часть времени грузятся именно кеды, а не сама система.

anti_win ★★ ()
Ответ на: комментарий от Flax187

у тебя видеокарта не работает из-за ошибки подгрузки прошивки, попробуй поставить современное ядро и последний linux-firmware, либо просто обнови дистр

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.