Ubuntu 20.04 занимает слишком много времени для загрузки
Я перешел с Windows 8 на ubuntu около 3 недель назад. У меня очень медленная загрузка. У меня нет двойной загрузки или чего-то еще. Мой компьютер - Lenovo 15-ay542tu с оперативной памятью 8 ГБ и жестким диском 1 ТБ.
Вот результат работы systemd-analysis blame:
53.630s plymouth-quit-wait.service
23.830s systemd-journal-flush.service
20.806s snapd.service
17.253s networkd-dispatcher.service
16.563s dev-sda2.device
15.555s libvirtd.service
15.205s NetworkManager-wait-online.service
13.684s apport-autoreport.service
13.634s udisks2.service
9.339s accounts-daemon.service
8.641s dev-loop17.device
8.478s dev-loop10.device
8.475s dev-loop15.device
8.475s dev-loop16.device
8.455s dev-loop19.device
8.448s dev-loop18.device
8.307s dev-loop20.device
7.500s dev-loop8.device
7.235s dev-loop4.device
7.195s ModemManager.service
7.123s dev-loop9.device
7.099s dev-loop12.device
6.948s dev-loop13.device
6.890s dev-loop14.device
6.876s polkit.service
6.808s dev-loop11.device
6.761s dev-loop7.device
6.580s avahi-daemon.service
6.578s bluetooth.service
6.500s NetworkManager.service
6.303s dev-loop2.device
6.191s switcheroo-control.service
6.179s thermald.service
6.176s systemd-logind.service
6.173s systemd-machined.service
6.156s wpa_supplicant.service
6.132s fwupd.service
5.977s dev-loop3.device
5.957s dev-loop5.device
5.790s dev-loop1.device
5.749s dev-loop6.device
5.115s bolt.service
4.925s dev-loop0.device
4.382s ufw.service
4.002s systemd-resolved.service
3.159s grub-common.service
2.911s grub-initrd-fallback.service
2.840s gpu-manager.service
2.740s systemd-udevd.service
2.406s gdm.service
2.168s apparmor.service
1.682s apport.service
1.654s rsyslog.service
1.529s motd-news.service
1.498s e2scrub_reap.service
1.294s snap-android\x2dstudio-91.mount
1.261s snapd.apparmor.service
1.228s snap-canonical\x2dlivepatch-95.mount
1.227s snap-code-39.mount
1.195s snap-code-40.mount
1.152s snap-core-9665.mount
1.151s snap-core-9804.mount
964ms snap-core18-1880.mount
886ms snap-core18-1885.mount
864ms snap-discord-112.mount
847ms systemd-tmpfiles-setup.service
834ms systemd-fsck@dev-disk-by\x2duuid-7D17\x2d84A2.service
833ms systemd-udev-trigger.service
784ms systemd-sysctl.service
753ms upower.service
748ms systemd-tmpfiles-setup-dev.service
720ms snap-figma\x2dlinux-70.mount
719ms snap-gnome\x2d3\x2d28\x2d1804-128.mount
654ms systemd-random-seed.service
632ms snap-gnome\x2d3\x2d34\x2d1804-24.mount
599ms snap-gnome\x2d3\x2d34\x2d1804-36.mount
590ms systemd-journald.service
572ms keyboard-setup.service
551ms systemd-modules-load.service
512ms swapfile.swap
500ms snap-gtk\x2dcommon\x2dthemes-1506.mount
499ms snap-intellij\x2didea\x2dcommunity-246.mount
497ms snap-snap\x2dstore-433.mount
467ms snap-snap\x2dstore-467.mount
451ms systemd-sysusers.service
388ms libvirt-guests.service
380ms plymouth-start.service
369ms lm-sensors.service
367ms snapd.seeded.service
348ms systemd-rfkill.service
331ms systemd-timesyncd.service
297ms modprobe@drm.service
294ms qemu-kvm.service
253ms dev-hugepages.mount
252ms dev-mqueue.mount
251ms systemd-user-sessions.service
251ms sys-kernel-debug.mount
249ms sys-kernel-tracing.mount
249ms kerneloops.service
247ms blk-availability.service
235ms snap-snapcraft-5279.mount
231ms kmod-static-nodes.service
230ms lvm2-monitor.service
228ms geoclue.service
206ms user@1000.service
189ms plymouth-read-write.service
188ms pppd-dns.service
186ms setvtrgb.service
185ms colord.service
184ms snap-snapd-8790.mount
183ms boot-efi.mount
181ms snap-snapcraft-5308.mount
179ms systemd-backlight@backlight:intel_backlight.service
153ms console-setup.service
112ms systemd-update-utmp.service
104ms snap-snapd-8542.mount
103ms systemd-remount-fs.service
102ms rtkit-daemon.service
88ms systemd-tmpfiles-clean.service
82ms hddtemp.service
78ms alsa-restore.service
38ms user-runtime-dir@1000.service
23ms systemd-update-utmp-runlevel.service
20ms openvpn.service
7ms sys-fs-fuse-connections.mount
4ms sys-kernel-config.mount
3ms libvirtd.socket
1ms snapd.socket
585us clean-mount-point@media-parag-My\x20Files.service
Вот результат работы systemd-analysis critical chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @1min 31.593s
└─multi-user.target @1min 31.593s
└─libvirt-guests.service @53.289s +388ms
└─libvirtd.service @37.692s +15.555s
└─network.target @37.655s
└─NetworkManager.service @31.155s +6.500s
└─dbus.service @31.150s
└─basic.target @30.972s
└─sockets.target @30.972s
└─libvirtd-ro.socket @30.972s
└─libvirtd.socket @30.967s +3ms
└─sysinit.target @30.781s
└─systemd-timesyncd.service @30.449s +331ms
└─systemd-tmpfiles-setup.service @29.579s +847ms
└─systemd-journal-flush.service @5.748s +23.830s
└─systemd-journald.service @5.156s +590ms
└─systemd-journald.socket @5.149s
└─system.slice @5.128s
└─-.slice @5.128s
Вот результат systemd- анализировать
Startup finished in 15.485s (firmware) + 4.343s (loader) + 3.662s (kernel) + 1min 31.784s (userspace) = 1min 55.275s
graphical.target reached after 1min 31.593s in userspace
Пожалуйста, предложите что-нибудь, я не знаю, что делать.
1 ответ
Вариант 1. Измените настройки различных служб, чтобы уменьшить время загрузки
Я дам вам несколько советов по systemd-journal-flush.service и libvirtd.service .
1. systemd-journal-flush.service:
Одним из главных виновников вашей медленной загрузки является systemd-journal-flush.service .
Проверьте размер вашего журнала:
journalctl --disk-usage
Вероятно, по какой-то причине он стал действительно большим.
Вы можете проверить, сколько времени потребовалось, чтобы очистить журнал, с помощью этого:
journalctl -b --unit systemd-journald.service
Вы можете уменьшить размер вашего журнала, используя параметры вакуума, например:
journalctl –vacuum-size=100M –vacuum-time=5d –vacuum-files=5
Затем проверьте использование вашего диска, чтобы узнать, не стал ли журнал меньше:
journalctl --disk-usage
Вы можете сделать определенные ограничения размера журнала постоянными:
Отредактируйте / etc / systemd / journald. conf , чтобы использовать auto в качестве параметра хранения и настроить максимальный размер файла, максимальное количество хранимых файлов или максимальный размер журнала (SystemMaxUse).
sudo nano /etc/systemd/journald.conf
Например, добавьте эти строки :
Storage=auto
SystemMaxUse=1G
SystemMaxFileSize=100M
SystemMaxFiles=5
См. Определения этих параметров здесь .
2. Libvirtd
Еще один фактор, увеличивающий время загрузки - это libvirtd.service , который занимает 15 секунд.
Вы используете виртуальную машину? В противном случае вы можете отключить запуск этой службы при загрузке.
sudo systemctl disable libvirtd
Возможно, вам также потребуется отключить гостей:
sudo systemctl disable libvirt-guests
Вариант 2: Обновление до SSD
Вы увидите значительное улучшение времени загрузки при замена жесткого диска 1 ТБ 5400 об / мин на SSD.
Storage=auto
SystemMaxUse=1G
SystemMaxFileSize=100M
SystemMaxFiles=5
См. Определения этих параметров здесь .
2. Libvirtd
Еще один фактор, увеличивающий время загрузки - это libvirtd.service , который занимает 15 секунд.
Вы используете виртуальную машину? В противном случае вы можете отключить запуск этой службы при загрузке.
sudo systemctl disable libvirtd
Возможно, вам также потребуется отключить гостей:
sudo systemctl disable libvirt-guests
Вариант 2: Обновление до SSD
Вы увидите значительное улучшение времени загрузки при замена жесткого диска 1 ТБ 5400 об / мин на SSD.
Storage=auto
SystemMaxUse=1G
SystemMaxFileSize=100M
SystemMaxFiles=5
См. Определения этих параметров здесь .
2. Libvirtd
Еще один фактор, увеличивающий время загрузки - это libvirtd.service , который занимает 15 секунд.
Вы используете виртуальную машину? В противном случае вы можете отключить запуск этой службы при загрузке.
sudo systemctl disable libvirtd
Возможно, вам также потребуется отключить гостей:
sudo systemctl disable libvirt-guests
Вариант 2: Обновление до SSD
Вы увидите значительное улучшение времени загрузки при замена жесткого диска 1 ТБ 5400 об / мин на SSD.