Problèmes et questions concernant le noyau et le support matériel.
Répondre

Analyse systemd

#1Messageil y a 5 ans

Bonsoir,

Est-ce normal que systemd soit si lent ?

systemd-analyze time
Startup finished in 11.088s (firmware) + 3.731s (loader) + 1.153s (kernel) + 1min 186ms (userspace) = 1min 16.159s
graphical.target reached after 16.398s in userspace
Plus d'une minute, avec un SSD ?? :siffle
C'est pas que cela me gêne mais...

Analyse systemd

#2Messageil y a 5 ans

:salut:
Heuhh. Donne nous le retour de systemd-analyze blame
Je suspecte un service long à démarrer. Le reste semble normal

Analyse systemd

#3Messageil y a 5 ans

reste normal ? :roll: 11s firmware = 11 secondes pour arriver à grub ; pas un foudre de guerre
normalement le tout est plutôt dans les 4..8 secondes sans le firmware

EDIT: oui pour le une minute, cela est généralement un timer suite à une erreur donc ssd ou pas c'est le même tarif :rigole:

Analyse systemd

#4Messageil y a 5 ans

Je m'interroge plus sur 1min 186ms (userspace) = 1min 16.159s donc post-chargement du noyau que le temps de chargement du bootloader . Reste que 11s pour le chargeur de démarrage est anormalement long. Cela dit, je ne peux comparer , je n'ai pas de W$ :gsourire:

Analyse systemd

#5Messageil y a 5 ans

Bonsoir aux habitués :siffle:siffle

Voici le systemd-analyze blame :

 48.247s man-db.service
         11.542s lvm2-monitor.service
          4.184s NetworkManager-wait-online.service
          3.072s dev-disk-by\x2duuid-501348ed\x2db7c3\x2d4502\x2d87e2\x2db6e7aa$
          1.150s systemd-journal-flush.service
           493ms systemd-logind.service
           323ms udisks2.service
           248ms lightdm.service
           245ms NetworkManager.service
           243ms upower.service
           233ms dev-sdd4.device
           194ms ModemManager.service
           167ms tlp.service
           147ms logrotate.service
           122ms systemd-fsck@dev-disk-by\x2duuid-e33e403e\x2d32fb\x2d4227\x2db$
           103ms polkit.service
            82ms systemd-journald.service
            81ms systemd-modules-load.service
            76ms ldconfig.service
            73ms avahi-daemon.service
            66ms home.mount
            46ms systemd-fsck@dev-disk-by\x2duuid-89B4\x2d5617.service
            43ms systemd-udev-trigger.service
            37ms teamviewerd.service
            25ms user@1000.service
            25ms systemd-udevd.service
            23ms org.cups.cupsd.service
            23ms systemd-sysusers.service
            19ms boot-efi.mount
            16ms systemd-tmpfiles-clean.service
            16ms pamac-system.service
            15ms systemd-tmpfiles-setup.service
            13ms systemd-journal-catalog-update.service
             8ms systemd-tmpfiles-setup-dev.service
             8ms ntpd.service
             7ms dev-hugepages.mount
             7ms sys-kernel-debug.mount
             7ms tmp.mount
             6ms systemd-random-seed.service
             5ms systemd-remount-fs.service
             4ms systemd-sysctl.service
             4ms systemd-update-utmp.service
             4ms kmod-static-nodes.service
             3ms sys-fs-fuse-connections.mount
             3ms systemd-update-done.service
             3ms systemd-user-sessions.service
             3ms rtkit-daemon.service
             2ms dev-mqueue.mount
             1ms sys-kernel-config.mount
Et je n'ai jamais monté mes partitions en LVM : pourquoi ce service se lance t-il ?

Analyse systemd

#6Messageil y a 5 ans

  11.542s lvm2-monitor.service
C'est là. Reste à savoir pourquoi le kernel prend autant de temps a vérifier les volumes. Une mise à jour partielle ?
Essaye depuis la distro maître

sudo pacman -Syyu
sudo grub-mkconfig -o /boot/grub/grub.cfg

Analyse systemd

#7Messageil y a 5 ans

tu peux le dévalider (si pas de lvm sur tes disques)

systemctl mask lvm2-monitor
tu as aussi cette commande pour analyser ton boot:

systemd-analyze critical-chain
seules les couleurs rouges sont importantes

---------
tu as aussi le man-db.service qui est très long ici mais normal (48s); on peut éventuellement changer le timer (une fois tous les 8 jours)
pour voir les réglages:

systemctl cat man-db.timer

Analyse systemd

#8Messageil y a 5 ans

Ok, j'essaierai depuis Archlinux demain car ici j'ai du boulot en cours.
Mais j'ai l'impression que dans la partition /boot/efi, c'est le souk !!

@papajoke (et aux autres :gsourire: )

Le retour de la première commande :

graphical.target @16.398s
└─multi-user.target @16.398s
  └─teamviewerd.service @16.360s +37ms
    └─network-online.target @16.360s
      └─NetworkManager-wait-online.service @12.175s +4.184s
        └─NetworkManager.service @11.929s +245ms
          └─dbus.service @11.927s
            └─basic.target @11.926s
              └─sockets.target @11.926s
                └─avahi-daemon.socket @11.926s
                  └─sysinit.target @11.925s
                    └─sys-fs-fuse-connections.mount @13.877s +3ms
                      └─systemd-journald.socket @104ms
                        └─system.slice @91ms
                          └─-.slice @91ms
En rouge : teamviewerd - etworkManager-wait-online.service - NetworkManager.service - sys-fs-fuse-connections.mount

Et la deuxième commande :

# /usr/lib/systemd/system/man-db.timer
[Unit]
Description=Daily man-db cache update

[Timer]
OnCalendar=daily
AccuracySec=1d
Persistent=true

Analyse systemd

#9Messageil y a 5 ans

pour que ce long process (man-db) ne soit lancé qu'une fois par semaine

sudo systemctl edit man-db.timer
et dans l'éditeur:

[Timer]
OnCalendar=
OnCalendar=weekly

Analyse systemd

#10Messageil y a 5 ans

Merci papajoke :gsourire:

@lemust :
C'est le grub de Manjaro qui est le maître :lolfou
J'ai donc fait la commande à partir de Manjaro, mais rien ne change...
Répondre