如何解决启动缓慢的问题?

如何解决启动缓慢的问题?

我正在运行 Windows 10 和 Ubuntu 16.04 的双启动桌面。虽然我的 Windows 启动速度非常快,但我的 Ubuntu 启动时间太长了。为了调查,我运行dmesg并发现了一些我认为可能是原因的消息。但是,我不确定这是否是事实,我是否可以做些什么来加快启动速度

以下是 dmesg 的最后几行

[   14.635266] Adding 4881404k swap on /dev/sda5.  Priority:-1 extents:1 across:4881404k FS
[   22.877684] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   22.884878] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   22.901317] IPv6: ADDRCONF(NETDEV_UP): enp6s0: link is not ready
[   22.901971] atl1c 0000:06:00.0: atl1c: enp6s0 NIC Link is Up<1000 Mbps Full Duplex>
[   24.055406] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   27.733484] audit_printk_skb: 42 callbacks suppressed
[   27.733487] audit: type=1400 audit(1495500079.496:26): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/1080/status" pid=1080 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=121 ouid=121
[   27.733510] audit: type=1400 audit(1495500079.496:27): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/" pid=1080 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=121 ouid=0
[   27.733538] audit: type=1400 audit(1495500079.496:28): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/1080/status" pid=1080 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=121 ouid=121
[  304.593596] SGI XFS with ACLs, security attributes, realtime, no debug enabled
[  304.631262] JFS: nTxBlock = 8192, nTxLock = 65536
[  304.666374] ntfs: driver 2.1.32 [Flags: R/O MODULE].
[  304.704295] QNX4 filesystem 0.2.3 registered.
[  304.817377] raid6: sse2x1   gen()  7149 MB/s
[  304.885373] raid6: sse2x1   xor()  6892 MB/s
[  304.953370] raid6: sse2x2   gen() 11874 MB/s
[  305.021366] raid6: sse2x2   xor()  8411 MB/s
[  305.089361] raid6: sse2x4   gen() 13842 MB/s
[  305.157356] raid6: sse2x4   xor() 10249 MB/s
[  305.157357] raid6: using algorithm sse2x4 gen() 13842 MB/s
[  305.157358] raid6: .... xor() 10249 MB/s, rmw enabled
[  305.157359] raid6: using ssse3x2 recovery algorithm
[  305.173207] xor: automatically using best checksumming function:
[  305.209351]    avx       : 23160.000 MB/sec
[  305.252714] Btrfs loaded

更新 以下是输出systemd-analyze blame

     16.105s grub-common.service
     15.804s [email protected]
     14.856s ondemand.service
     14.080s networking.service
     14.057s apport.service
     13.611s mysql.service
     13.265s speech-dispatcher.service
     12.494s irqbalance.service
     10.698s sysstat.service
     10.641s lightdm.service
      7.857s dev-sda6.device
      5.599s ModemManager.service
      4.685s apparmor.service
      4.666s accounts-daemon.service
      3.626s NetworkManager.service
      2.811s redis-server.service
      2.670s systemd-logind.service
      2.583s upower.service
      2.506s gpu-manager.service
      2.442s systemd-user-sessions.service
      2.061s console-setup.service
      1.994s thermald.service
      1.756s systemd-tmpfiles-setup.service
      1.726s setvtrgb.service
      1.243s keyboard-setup.service
      1.194s systemd-udevd.service
      1.166s rsyslog.service
      1.054s plymouth-start.service
      1.026s systemd-tmpfiles-setup-dev.service
       902ms colord.service
       868ms avahi-daemon.service
       614ms systemd-modules-load.service
       578ms wpa_supplicant.service
       555ms systemd-rfkill.service
       537ms systemd-journald.service
       420ms sys-kernel-debug.mount
       420ms dev-mqueue.mount
       419ms dev-hugepages.mount
       348ms polkitd.service
       345ms systemd-update-utmp.service
       345ms systemd-timesyncd.service
       337ms apt-daily.service
       336ms systemd-sysctl.service
       333ms dns-clean.service
       311ms udisks2.service
       310ms plymouth-read-write.service
       301ms systemd-journal-flush.service
       276ms ufw.service
       276ms kmod-static-nodes.service
       214ms systemd-udev-trigger.service
       192ms resolvconf.service
       132ms systemd-random-seed.service
       126ms dev-disk-by\x2duuid-0b399021\x2dd995\x2d469b\x2d9027\x2d01183ad502e6.swap
       100ms systemd-remount-fs.service
        91ms pppd-dns.service
        36ms snapd.socket
        17ms [email protected]
         8ms snapd.autoimport.service
         7ms alsa-restore.service
         3ms ureadahead-stop.service
         3ms systemd-update-utmp-runlevel.service
         2ms rtkit-daemon.service
         2ms rc-local.service
         1ms sys-fs-fuse-connections.mount
       900us plymouth-quit-wait.service
       670us postgresql.service

答案1

真正诊断问题的最佳方法是使用来自 的调用组合systemd-analyze。此工具不仅可以帮助您识别问题,还可以为您提供视觉表示。

  1. 执行如下所示的基本诊断。查看最普遍的项目并确定是否无法停止自动启动或修改某些配置

      systemd-analyze blame
       8.121s apt-daily.service
       7.658s NetworkManager-wait-online.service
       931ms docker.service
       710ms winbind.service
       695ms nmbd.service
       647ms samba-ad-dc.service
       543ms ModemManager.service
    
  2. 如果上面的列表还不足以解释这一点,那么下一个最佳选择是使用绘图工具。这会将整个启动过程输出到 svg 文件中。是的,然后您就可以直观地看到问题了!您只需输入systemd-analyze plot > test.svg

  3. 打开 test.svg 并查看占用大量时间的各种服务。然后将它们从自动启动中删除,或者确定是否有可以进行配置来修复它们

  4. 重新启动计算机并再次运行步骤 2,查看是否还有其他问题

相关内容