Como consertar a inicialização lenta?

0

Estou executando um desktop de inicialização dupla com o Windows 10 e o Ubuntu 16.04. Enquanto minha inicialização do Windows é muito rápida, meu Ubuntu leva muito tempo. Para investigar, eu corri dmesg e encontrei algumas mensagens que acredito que possam ser a causa. No entanto, não tenho certeza se esse é realmente o caso e se posso fazer algo para acelerar a inicialização

Aqui estão as últimas linhas do 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

Atualizar Aqui está a saída de 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
    
por Ankit 23.05.2017 / 02:59

1 resposta

0

A melhor maneira de realmente diagnosticar problemas é usar uma combinação de chamadas de systemd-analyze . Essa ferramenta não apenas ajuda a identificar problemas, mas também fornece representações visuais.

  1. Execute um diagnóstico básico como mostrado abaixo. Veja os itens mais difusos e determine se você não pode parar a inicialização automática ou modificar algumas configurações

      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. Se a listagem acima não explicar o suficiente, a próxima melhor opção é usar a ferramenta de plotagem. Isto irá mostrar todo o processo de inicialização em um arquivo svg. Sim, então você pode ver visualmente os problemas! Você simplesmente digita systemd-analyze plot > test.svg

  3. Abra o test.svg e dê uma olhada nos vários serviços que estão planejando uma quantidade maior de tempo. Em seguida, remova-os do início automático ou determine se existem configurações que possam ser feitas para corrigi-los

  4. Reinicialize a máquina e execute a Etapa 2 novamente para ver se há outros problemas restantes

por shaneonabike 04.02.2018 / 02:15