Lenteurs au démarrage (boot et session XFCE)

Support Debian
Tags: #<Tag:0x00007f63f2e07b00>
#1

Bonjour à toutes et à tous,

depuis un moment (je ne saurais pas trop dire exactement), mon système est relativement lent à booter et à arriver jusqu’au login de connexion graphique, d’une part, et c’est aussi lent à l’ouverture de la session xfce. Il faut ajouter à cela que tout semble ralenti, l’apparition du menu laggue, et par exemple gimp est long à démarrer (~ 10 secondes ressenties avant l’apparition du splash-screen.). Les lenteurs de boot et de la session xfce sont peut être deux sujets différents, d’ailleurs.

Je ne saurais pas trop dire depuis quand c’est comme ça (oui je sais, c’était mieux avant, mais avant quoi ?? :slight_smile: ) , si c’est depuis le passage à bullseye ou autre. Je précise que j’ai un disque ssd pour le système, et un dd SATA pour le /home.
J’ai des répertoires montés sur un serveur NAS mais si j’enlève ces répertoires de mon fichiers fstab et que je redémarre le gain n’est pas flagrant.

J’ai essayé d’enlever pas mal de packages que j’estimais inutiles ; ça m’a fait gagner quelques secondes mais rien de satisfaisant.

Je suis un peu démuni parce que je ne sais pas trop dans quelle direction chercher. Si vous avez des pistes, ça m’intéresse :slight_smile:

Quelques pistes :

$ grep -v ^# /etc/fstab 
UUID=f05bee2c-64ec-4b44-8e34-36374a1f4445 /               ext4    errors=remount-ro,noatime,nodiratime 0       1
UUID=D4F9-6314  /boot/efi       vfat    umask=0077      0       1
/dev/sdb8 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/sdb2	/home	xfs	defaults	0	0	
tmpfs	/tmp	tmpfs	defaults,size=1000m	0	0 
nas:/volume1/music /srv/music  nfs user,auto,rw,x-systemd.automount 0 0 
nas:/volume1/video /srv/video  nfs user,auto,rw,x-systemd.automount 0 0 
nas:/volume1/photo /srv/photos  nfs user,auto,rw,x-systemd.automount 0 0 
nas:/volume1/Backup /srv/backup  nfs user,auto,rw,x-systemd.automount 0 0 

$ systemd-analyze
Startup finished in 14.680s (firmware) + 5.469s (loader) + 7.158s (kernel) + 1min 24.260s (userspace) = 1min 51.568s 
graphical.target reached after 36.399s in userspace

tanguy@avalon:~$ systemd-analyze blame
1min 7.248s man-db.service
    19.405s udisks2.service
    12.103s logrotate.service
     8.252s cups.service
     6.647s systemd-journal-flush.service
     5.700s apparmor.service
     3.446s upower.service
     2.645s systemd-tmpfiles-clean.service
     1.475s accounts-daemon.service
     1.233s srv-backup.mount
     1.167s colord.service
     1.112s systemd-resolved.service

(j’ai gardé les premières lignes du systemd-analyze blame)

#2

Bonjour,

ça me paraît beaucoup pour régénérer la bdd de man ! Sur quelques machines testées, on est plutôt sur quelques millisecondes.

Essaie d’exécuter manuellement le service, pour voir si quelque chose coince ? (d’ordinaire, le service est appelé par le timer man-db.timer sur une base quotidienne, tu peux l’exécuter manuellement avec systemctl start man-db.service par exemple).

Oui c’est possible. Tu as vérifié la consommation de ressources durant une session xfce « classique » ? Ainsi que l’état du matériel (disques, mémoire, etc.) ?

#3

merci pour ta réponse.
J’ai exécuté systemctl start man-db.service deux fois. La première fois ça a mis de longues secondes, la deuxième fois ça a été instantané ou presque.

~$ time systemctl start man-db.service 
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentification requise pour démarrer « man-db.service ».
Authenticating as: root
Password: 
==== AUTHENTICATION COMPLETE ===

real	0m1,879s
user	0m0,019s
sys	0m0,010s

pour vérifier l’état du matériel, je ne sais pas trop comment faire (?).
je vais tenter un memtest pour voir…

#4

Oui, tu peux faire un memtest, ainsi qu’un contrôle smart pour les disques.

#5

aucun de ces deux outils ne remonte d’erreurs.

#6

Et pour la consommation de ressources quand tu constates un ralentissement ? En faisant un top ou autres ?

#7

rien qui me choque spécialement. (Je teste en lançant gimp : Le comportement est vraiment étrange. Ca reste bloqué de loooooonngues secondes, et tout d’un coup ça se débloque, le splash apparaît, il charge ses plugins très rapidement et les fenêtres de l’interface apparaissent. Tout ceci au premier lancement, un redémarrage est très rapide, sans le temps de bloquage). Le top remonte un petit pourcentage d’utilisation, mais rien de spécial.

#8

Bon, pour GIMP je trouve pas ça super choquant, que le premier démarrage prenne un certain temps. A voir si tu observes des ralentissements plus surprenants (comme un freeze général pendant une session avec peu d’applications lourdes ouvertes, etc.)

Par contre, la durée d’exécution du service man-db est peut-être symptomatique d’un soucis, mais je sais pas bien comment analyser. Peut-être augmenter la verbosité des journaux systemd avant de démarrer manuellement le service, ou exécuter à la main les directives ExecStart…

#9

Bonjour

Agrandis d’abord la fenêtre de terminal
et donne nous le retour de la ligne de commande suivante :

lsblk -oSIZE,FSSIZE,FSUSED,NAME,FSTYPE,MOUNTPOINT,LABEL,UUID
#10

Salut, as-tu regardé le taux de remplissage de tes partitions?

Si besoin tu peux virer les paquets de /var/cache/apt/archives (en root et ne pas virer le dossier « partial » ou quelquechose du genre).

De même avec /tmp/, /local/tmp/ etc…

Vérifie aussi ton occupation de bande passante réseau, si c’est assez actif → détecteur de rootkit, analyse système etc!

#11

Bon, pour GIMP je trouve pas ça super choquant, que le premier démarrage prenne un certain temps. A voir si tu observes des ralentissements plus surprenants (comme un freeze général pendant une session avec peu d’applications lourdes ouvertes, etc.)

certes mais avant les temps de démarrage étaient bien inférieurs, et l’ensemble du système est moins réactif qu’avant (l’appel au menu par exemple met plusieurs longues secondes à le faire apparaître)

#12

voici la sortie le la commande lsblk

  SIZE FSSIZE FSUSED NAME   FSTYPE MOUNTPOINT LABEL UUID
111,8G               sda                            
 37,3G  36,4G  18,2G ├─sda1 ext4   /                f05bee2c-64ec-4b44-8e34-36374a1f4445
  3,7G               ├─sda2 swap                    c26fe525-deec-48fe-9a19-523d027d4f05
  477M   476M   3,4M ├─sda3 vfat   /boot/efi        D4F9-6314
 11,2G               ├─sda4 ext4                    44529459-a57b-4422-82f8-6e2ada50de1a
 37,3G               └─sda5 ext4                    2b70955a-bf50-47b6-af1a-0d5af5b18712
931,5G               sdb                            
  400G               ├─sdb1 xfs                     be357aba-9c0f-4689-b725-ad119da10c87
  200G 199,9G   173G ├─sdb2 xfs    /home            73eb27b5-f282-45e4-a2c2-de54af21e69b
    1G               ├─sdb3 swap                    14b05a09-e4d0-4870-b17c-9a7b7ce33216
    1K               ├─sdb4                         
    1G               ├─sdb5 ext3                    fec82825-4586-4242-9f78-893736c88ff2
    5G               ├─sdb6 ext3                    14ac5a31-9183-45f3-9bd5-2a9fc00670b4
    2G               ├─sdb7 ext4                    c652b351-bed3-40aa-9b7c-95624480015d
    2G               └─sdb8 swap   [SWAP]           a6d9c43b-d9b8-443b-b13e-cbf69c3b64a9
#13

Merci pour le retour de la commande lsblk

Je pensais qu’un manque d’espace dans un des systèmes de fichiers utilisés aurait pu être la cause du problème, mais non, il y a assez d’espace disponible.

Ça n’a rien à voir avec le problème rencontré,
mais, comme conseillé dans les commentaires qui sont indiqués dans les premières lignes du fichier /etc/fstab

il vaudrait mieux utiliser les UUIDs des systèmes de fichiers plutôt que les noms des fichiers de périphériques associés aux partitions qui contiennent ces systèmes de fichiers.

Donc, je te propose de remplacer les lignes suivantes :

/dev/sdb8 none            swap    sw              0       0
/dev/sdb2	/home	xfs	defaults	0	0

par les lignes suivantes :

UUID=a6d9c43b-d9b8-443b-b13e-cbf69c3b64a9 none            swap    sw              0       0
UUID=73eb27b5-f282-45e4-a2c2-de54af21e69b	/home	xfs	defaults	0	0

en lançant, avec les privilèges du compte root
la ligne de commande suivante :

sed -i 's#^/dev/sdb8#UUID=a6d9c43b-d9b8-443b-b13e-cbf69c3b64a9#; s#^/dev/sdb2#UUID=73eb27b5-f282-45e4-a2c2-de54af21e69b#' /etc/fstab
#14

salut
j’ai les mêmes problèmes de lenteur sur tous les ordis.
Je pense que c’est arrivé avec mon utilisation de systemd
j’ai l’impression que systemd :

  • démarre cups et attend une réponse de mon imprimante et si elle est éteinte elle réessaye sans commencer les autres services
  • démarre bluetooth et attend le lien avec la dernière connexion et réessaye sans commencer les autres services

systemd-analyze plot te donne un graphique mais je ne sais pas vraiment l’analyser

#15

Vérifie aussi ton occupation de bande passante réseau, si c’est assez actif → détecteur de rootkit, analyse système etc!

je n’ai rien trouvé avec rkhunter ni chkrootkit. (après je ne suis pas spécialiste de ces outils, j’espère les avoir lancés avec les bonnes options)

Pour info, je suis en train d’installer un bullseye sur une partition à côté pour comparer. Et bien ça n’a rien à voir, je ne constate pas du tout ces temps de latence sur la nouvelle install. :confused:
Je me demande si je ne vais pas rester sur cette dernière install (mais ça m’embêterait bien de faire ça plutôt que de trouver la vraie solution)

#16

Est-ce que le nouveau système debian 11 Xfce installé utilise aussi un système de fichiers de type xfs pour le répertoire /home/ ?

Comme j’avais vu qu’il y avait la place pour le faire, j’avais justement pensé à te proposer de créer un nouveau système de fichiers de type ext4 pour remplacer temporairement celui que tu utilises pour le répertoire /home/
mais bon, ça aurait demandé de faire une copie de 173GB de données, donc ça aurait pris …un certain temps à faire et je n’étais pas sûr du tout que le problème vienne de là, alors je ne l’ai pas proposé.

#17

Est-ce que le nouveau système debian 11 Xfce installé utilise aussi un système de fichiers de type xfs pour le répertoire /home/ ?

oui oui, c’est la même partition montée dans le répertoire /home dans les deux cas

#18

Impec, donc ça n’est pas du tout un problème de système de fichiers.

Alors c’est que le problème est tailleur :slight_smile:

#19

Tu peux essayer systemd-bootchart, ça te génère un graphe plus facile à lire…