J'ai cesse de chercher à comprendre pourquoi mon PC sous Linux était lent en utilisant une seule commande pour le découvrir

Résumé : Plutôt que de blâmer le matériel ou de désactiver des services au hasard, il faut utiliser l'outil natif systemd-analyze pour diagnostiquer précisément la lenteur du démarrage sous Linux. L'importance est de ne pas se fier uniquement à la commande blame, qui liste les services les plus longs, mais de se concentrer sur la chaîne critique (critical-chain) : cette séquence de services interdépendants qui bloque réellement l'accès au système. En utilisant ces outils et en visualisant le processus via un graphique (plot), l'utilisateur peut enfin distinguer les processus qui tournent inoffensivement en arrière-plan des véritables goulots d'étranglement, permettant ainsi une optimisation ciblée et efficace. 

Mon PC sous Linux n'était pas en panne. Il avait juste tendance à prendre son temps, comme s'il s'arrêtait d'un coup au milieu de la procédure d'ouverture de session. Certains démarrages étaient rapides, d'autres s'éternisaient au point de m'amener à me demander si quelque chose n'allait pas. J'ai donc fait ce que font la plupart des gens : j'ai redémarré, j'ai modifié quelques paramètres que je ne comprenais pas tout à fait, puis j'ai attendu de voir si ça s'améliorait.

Finalement, j'ai pris le temps d'observer ce qui se passait réellement pendant le démarrage. Linux n'est pas lent, il est simplement très discret quant à l'utilisation de son temps. Après avoir levé le voile et vu le processus se dérouler étape par étape, j'ai compris.

Votre PC sous Linux n'est pas vraiment lent, c'est juste que vous ignorez ce qui prend du temps.

Lorsque le démarrage d'un système Linux prend trop de temps, cela peut sembler aléatoire. Un jour, il s'allume en un clin d'œil, et le lendemain, il reste figé comme s'il avait oublié ce qu'il était censé faire. Il est alors facile de supposer qu'il y a un problème indéfinissable avec le système dans son ensemble. On redémarre en espérant que ça passe. On commence à désactiver des fonctionnalités sans vraiment savoir de quoi il s'agit. On accuse le matériel. C'est peut-être le SSD. C'est peut-être la RAM. C'est peut-être simplement « Linux qui est Linux »

Le problème, c'est que les démarrages lents ne sont généralement pas dus à un seul problème. Le retard peut provenir d'une succession d'étapes différentes qui se succèdent. Cela peut se produire avant même que le système d'exploitation ne se charge, pendant les vérifications du firmware. Cela peut se produire pendant que le noyau initialise le matériel. Ou cela peut être causé par des services qui démarrent une fois que le système est déjà opérationnel.

Linux ne cache rien. C'est juste qu'il ne vous le montre pas par défaut. Une fois que vous mesurez réellement le processus de démarrage et que vous le décomposez en parties, vous comprenez mieux ce qui se passe. Vous pouvez voir à quoi le temps est consacré, et surtout, ce qui vaut la peine d'être corrigé et ce qui n'en vaut pas la peine. 

Cet outil intégré vous indique ce qui ralentit le démarrage de votre ordinateur

La plupart des systèmes Linux fonctionnent aujourd’hui avec un gestionnaire appelé systemd. Il gère le démarrage, exécute les services et assure le bon fonctionnement de l’ensemble. Il intègre un petit outil appelé systemd-analyze. Vous n’avez rien à installer en plus. Cet outil examine le processus de démarrage et détaille la durée de chaque étape. Il indique le temps réel écoulé lors du dernier démarrage.

Pour commencer, lancez cette commande toute simple : systemd-analyze. Le résultat vous donne un résumé rapide. Vous verrez combien de temps le noyau a mis pour s’initialiser et combien de temps l’espace utilisateur a mis pour démarrer. La phase du noyau couvre la configuration de bas niveau, comme l’initialisation du matériel. L’espace utilisateur inclut tout ce qui s’exécute après, comme les services et les processus en arrière-plan. Vous verrez également la durée totale du démarrage, ainsi que le moment où le système a atteint son objectif graphique. C'est généralement le moment où l'écran de connexion apparaît.

C'est là que le brouillard commence à se dissiper. Si la majeure partie du retard se situe dans l'espace utilisateur, vous devez vous pencher sur les services. S'il s'agit du noyau, le problème se trouve ailleurs. 

« Blame » montre ce qui semble lent, mais pas vraiment ce qui compte

Une fois que vous disposez de la base de référence, l'étape suivante consiste à identifier les services qui ont mis le plus de temps à démarrer. C'est là que la commande `systemd-analyze blame` vous sera utile. Exécutez cette commande pour obtenir une liste des services triés du plus lent au plus rapide. Chaque entrée indique le temps qu'un service a mis à s'initialiser lors du dernier démarrage. Cela peut sembler être ce dont vous avez besoin, mais il est facile de se tromper.

Les services en haut de la liste peuvent sembler alarmants en raison de leurs durées élevées. Mais un temps de démarrage long ne signifie pas toujours que ce service ralentit votre démarrage de manière significative. Certains services sont conçus pour s'exécuter en arrière-plan et n'empêchent pas le reste du système de continuer. D'autres, comme les services de vérification des mises à jour ou les services de containérisation, peuvent prendre du temps pour des raisons valables.

C'est là que certaines personnes commettent une erreur. Lorsqu'elles voient un service avec un temps élevé, elles supposent que c'est celui-ci qui pose problème. Or, ce service n'affecte peut-être pas le moment où votre système devient utilisable. La sortie « blame » est un point de départ, mais pas une conclusion. Elle vous donne une liste de suspects, mais ne vous indique pas lequel a réellement ralenti le système. 

C'est dans la chaîne critique que se cachent les véritables goulots d'étranglement

Vous devez examiner les dépendances pour comprendre ce qui ralentit réellement votre système. Certains services doivent attendre que d'autres aient terminé avant de pouvoir démarrer. Cela crée une chaîne, et si un maillon de cette chaîne est retardé, tout ce qui vient après est également retardé.

Vous pouvez voir cela avec : systemd-analyze critical-chain. Cette commande affiche la séquence des services qui influent directement sur le temps nécessaire pour obtenir un système opérationnel. Cette commande affiche la date et l'heure de démarrage de chaque service, la durée de son exécution, ainsi que l'ordre dans lequel ils dépendent les uns des autres.

C'est là la différence importante par rapport à l'étape précédente. Un service peut sembler lent dans blame, mais s'il ne fait pas partie de la chaîne critique, il ne ralentit rien. Il s'exécute simplement en parallèle. En revanche, un service faisant partie de la chaîne critique a un impact direct sur le moment où votre système est prêt à fonctionner.

C'est souvent à ce stade que se manifestent les retards courants dans les systèmes en temps réel. Les services d'attente réseau peuvent suspendre le démarrage en attendant une connexion. Les services de conteneurs peuvent retarder les processus qui en dépendent. Des problèmes matériels ou des délais d'attente des pilotes peuvent également survenir dans cette chaîne.

Si vous souhaitez une représentation visuelle, vous pouvez également générer une chronologie avec : systemd-analyze plot > boot.svg. Cela crée un graphique du processus de démarrage que vous pouvez ouvrir dans un navigateur. Ce n'est pas obligatoire, mais cela peut vous aider à voir comment les différents services s'imbriquent les uns dans les autres. 

Pour optimiser le temps de démarrage, il faut d'abord identifier ce qui importe vraiment

Tout cela devient beaucoup moins compliqué une fois que vous avez identifié l'origine du ralentissement. Au lieu de tâtonner à l'aveuglette, vous apportez des modifications ciblées. Vous pouvez retarder le démarrage d'un service dont vous n'avez pas besoin au démarrage. Vous pouvez arrêter un processus qui n'a pas lieu de s'exécuter à chaque démarrage. Vous vous rendez peut-être compte qu'il ne s'agit même pas d'un service, mais d'un problème matériel ou de pilote qui ralentit le système.

Le plus important est de savoir ce qu'il ne faut pas modifier. Certaines étapes lentes sont normales et n'affectent pas le moment où le système est réellement utilisable. Le véritable atout ici, c'est le discernement. Une fois que vous l'avez, vous cessez de deviner et commencez à corriger ce qu'il faut. 

traduction de : https://www.xda-developers.com/your-linux-pc-is-probably-booting-slower-than-it-should/