Ubuntu 24.04 : Performances en chute après une mise à jour — les 6 premières vérifications qui révèlent le coupable

novembre 8, 2025 • février 3, 2026 • Lecture : 28 min • Views: 10

Cet article vous a aidé ?

C’est le classique : vous appliquez un patch sur une machine Ubuntu qui fonctionnait très bien, vous redémarrez, et soudain votre système « réactif » donne l’impression de marcher dans du ciment mouillé. Les tableaux de bord laguent. Les déploiements rampent. Les graphiques d’E/S ressemblent à un moniteur cardiaque. Votre premier réflexe est d’accuser « la mise à jour » comme une masse unique. C’est satisfaisant émotionnellement. C’est aussi inutile opérationnellement.

Les régressions de performance sont généralement une ou deux goulots concrets déguisés. Le travail consiste à les repérer rapidement, déterminer s’il s’agit de vraies régressions ou simplement de nouveaux comportements par défaut, et prendre une décision calme : revenir en arrière, ajuster, ou attendre une correction en amont.

Playbook de diagnostic rapide (quoi vérifier en priorité)

Si vous n’avez que 15 minutes avant qu’on ne vous relance, faites ceci dans l’ordre. Le but n’est pas de collecter des données pour un musée. Le but est d’identifier la classe de goulot la : CPU, pression mémoire, latence disque, réseau, ou « un nouveau service dévore l’hôte ».

1) Confirmer ce qui a changé (noyau, microcode, pilotes, services)

Vérifiez le noyau courant et l’heure du dernier démarrage.
Listez les packages récemment mis à jour et les unités nouvellement activées.
Cherchez de nouveaux rafraîchissements snap si vous utilisez intensivement snap.

2) Classer la lenteur : CPU-bound vs I/O-bound vs mémoire

Si la charge est élevée et que iowait est haute, c’est généralement lié au stockage ou au comportement du système de fichiers.
Si le CPU est saturé en mode user/system avec un faible iowait, c’est un processus qui part en roue libre, une tempête d’appels système, ou un nouveau démon « utile ».
Si vous voyez une activité de swap importante, il s’agit de pression mémoire ou d’une régression du working set.

3) Identifier le processus principal responsable et confirmer sa corrélation avec la lenteur

Ne vous arrêtez pas à « top dit que X utilise le CPU ». Vérifiez s’il est bloqué sur du disque ou en attente de verrous.

4) Mesurer la latence disque (pas le débit) et l’encombrement

Le débit peut sembler correct tandis que la latence détruit les performances de queue.
Confirmez si c’est un seul périphérique, un seul système de fichiers, ou une option de montage particulière.

5) Vérifier la mise à l’échelle de la fréquence CPU et les profils d’alimentation

Après des mises à jour, les valeurs par défaut liées à l’alimentation et les pilotes peuvent changer. Si votre CPU reste coincé en mode powersave, tout paraît « mystérieusement lent ».

6) Ensuite seulement : creuser les logs du noyau, les régressions de pilote, les denials AppArmor et la croissance de journald/log

Ce sont des causes courantes sur Ubuntu 24.04 parce que la plateforme est moderne et active : nouveaux noyaux, nouveaux pilotes et nouvelles politiques.

Une idée paraphrasée de Gene Kim (auteur DevOps) que les équipes d’exploitation devraient inscrire sur leurs runbooks : optimisez pour une détection rapide et une récupération rapide, pas pour une prévention parfaite. Cet état d’esprit est ce qui vous garde sain d’esprit pendant la saison des « c’est devenu lent ».

Les 6 premières vérifications qui révèlent généralement le coupable

Vérification 1 : Exécutez-vous réellement le noyau que vous croyez exécuter ?

Après des mises à jour, « nous avons mis à niveau » et « nous exécutons le noyau mis à niveau » ne sont pas la même chose. Si vous utilisez Livepatch, plusieurs noyaux, ou des redémarrages différés, vous pouvez être dans un état semi-mis à jour où l’espace utilisateur attend un comportement et le noyau en fournit un autre. Aussi : un nouveau noyau peut avoir changé un chemin de pilote (NVMe, réseau, GPU), et vous pouvez ainsi subir une régression.

Vérification 2 : Le système est-il lié aux E/S (iowait, latence disque, profondeur de file) ?

Les régressions d’E/S sont la principale source de plaintes « toute la machine est lente » car elles frappent tout : le démarrage, l’installation de paquets, les commits de base de données, les redémarrages de service, les écritures de logs. Après une mise à jour, les déclencheurs courants incluent :

Options de montage du système de fichiers modifiées ou « améliorées ».
Volume de journald augmenté et qui force plus de synchronisations.
Snap refreshes qui démarrent à des moments inopportuns.
Modifications du pilote de stockage (NVMe/APST, ordonnanceur, multipath).

Vérification 3 : La pression mémoire force-t-elle le reclaim ou le swap ?

Ubuntu 24.04 fonctionne bien sur du matériel moderne, mais votre charge de travail peut ne pas l’être. Une mise à jour de package peut changer les tailles de cache par défaut, introduire un nouveau service ou mettre à niveau un runtime qui augmente la mémoire. Une fois en reclaim soutenu, vous verrez une lenteur « aléatoire » : tout attend la gestion mémoire.

Vérification 4 : Le scaling de la fréquence CPU / le mode d’alimentation a-t-il changé ?

Sur les portables c’est évident. Sur les serveurs c’est plus sournois. Un changement de profil d’alimentation, de réglages BIOS, de microcode ou de pilote peut maintenir les cœurs à basse fréquence sous charge ou les faire osciller. Cela ressemble à « le CPU n’est qu’à 40% mais les requêtes sont lentes ».

Vérification 5 : Un service a-t-il été activé, reconfiguré ou se met-il à thrash ?

Systemd facilite l’activation de services. Les mises à jour peuvent aussi changer des valeurs par défaut d’unités. Un petit démon qui faisait « juste un peu de scan » devient un crawler disque 24/7 sur des systèmes de fichiers volumineux. Les suspects habituels : indexeurs, agents de sécurité, hooks de sauvegarde, expéditeurs de logs, et tout ce qui « découvre » des images de conteneur.

Vérification 6 : Les logs du noyau montrent-ils des erreurs, des resets ou des refus de politique ?

Si les performances ont chuté, c’est souvent parce que le système réessaie quelque chose. Link flaps. Reset NVMe. Avertissements de système de fichiers. AppArmor qui refuse un chemin chaud, provoquant des retries et des repliements inattendus. Les logs du noyau sont l’endroit où le corps est enterré.

Blague #1 : La seule chose plus constante que « ça a ralenti après la mise à jour » est « c’était déjà lent, la mise à jour a juste attiré l’attention ».

Tâches pratiques : commandes, interprétation, décisions (12+)

Voici les tâches que j’exécute sur de vraies machines de production parce qu’elles répondent vite aux questions. Chaque tâche inclut : une commande, ce que signifie la sortie, et la décision à prendre. Exécutez-les en tant qu’utilisateur avec sudo si nécessaire.

Tâche 1 : Confirmer le noyau, l’heure de démarrage et la plateforme de base

cr0x@server:~$ uname -a
Linux server 6.8.0-41-generic #41-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux
cr0x@server:~$ uptime -s
2025-12-29 02:14:03

Signification : Vous voyez exactement quel noyau est actif et quand la machine a démarré. Si la mise à jour a eu lieu mais que uptime est antérieur, vous n’avez pas redémarré et vous ne testez pas le noyau mis à jour.

Décision : Si la régression a commencé seulement après le redémarrage, suspectez le noyau/les pilotes/les services. Si elle a commencé avant le redémarrage, suspectez des mises à jour en espace utilisateur ou des tâches en arrière-plan (snap refreshes, indexeurs, croissance des logs).

Tâche 2 : Lister les mises à jour récentes pour corréler le « début de la lenteur »

cr0x@server:~$ grep -E " upgrade | install " /var/log/dpkg.log | tail -n 15
2025-12-28 21:05:12 upgrade linux-image-6.8.0-41-generic:amd64 6.8.0-40.40 6.8.0-41.41
2025-12-28 21:05:20 upgrade linux-modules-6.8.0-41-generic:amd64 6.8.0-40.40 6.8.0-41.41
2025-12-28 21:06:01 upgrade systemd:amd64 255.4-1ubuntu8 255.4-1ubuntu9
2025-12-28 21:06:29 upgrade openssh-server:amd64 1:9.6p1-3ubuntu13 1:9.6p1-3ubuntu14

Signification : Montre ce qui a changé récemment. Les mises à jour du noyau et de systemd sont des suspects à fort levier car ils touchent le boot, la gestion des périphériques, les cgroups et le logging.

Décision : Choisissez 1–3 mises à jour « les plus suspectes » et vérifiez leur changelog pour l’impact dans votre environnement (en particulier le noyau et la pile stockage/réseau).

Tâche 3 : Vérifier systemd pour unités échouées et services lents au démarrage

cr0x@server:~$ systemctl --failed
  UNIT                 LOAD   ACTIVE SUB    DESCRIPTION
● fwupd.service         loaded failed failed Firmware update daemon
cr0x@server:~$ systemd-analyze blame | head
35.114s snapd.seeded.service
12.892s dev-nvme0n1p2.device
 8.310s systemd-journald.service
 6.942s NetworkManager-wait-online.service

Signification : Les unités échouées peuvent provoquer des boucles de retry. La sortie blame montre ce qui mange le temps au démarrage ; c’est aussi un indice sur la lenteur en runtime (ex. journald prend du temps, périphériques lents à apparaître).

Décision : Si une unité échoue ou redémarre, corrigez-la en priorité. Si snapd seeding domine et coïncide avec la lenteur, vous avez probablement de la churn I/O en arrière-plan.

Tâche 4 : Identifier les principaux consommateurs actuels (CPU, mémoire) sans deviner

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem,etimes,state --sort=-%cpu | head -n 12
  PID COMMAND         %CPU %MEM ELAPSED S
 2143 node            280.5  6.1   15421 R
  982 systemd-journal   32.1  0.3   86322 R
 1777 snapd            24.8  0.6   74210 S
 1460 postgres         18.2 12.4   99111 S

Signification : Vous obtenez une liste classée, avec le temps écoulé et l’état. « R » signifie running ; « D » (uninterruptible sleep) signifie souvent bloqué sur des E/S.

Décision : Si un processus bourre le CPU, creusez. Si beaucoup de processus importants sont en « D », arrêtez de blâmer le CPU et allez vers le stockage.

Tâche 5 : Vérifier la charge, iowait et les changements de contexte

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0  10240 812344  92160 6123456   0    0   112   205 3210 5400 18  6 70  6  0
 6  3  10304  92344  90240 5943120  40   88  9800  6100 5400 8800 22  9 40 29  0
 4  2  10496  74320  90112 5901220  52  140 10400  7200 5900 9400 18 10 41 31  0
 7  4  10560  70212  90224 5899900  60  160 12000  8400 6100 9900 16 11 38 35  0
 3  1  10560  69300  90240 5898000   0    0  2100  1900 4100 7200 14  8 70  8  0

Signification : Surveillez wa (I/O wait) et les échanges (si/so). Une activité de swap soutenue signifie pression mémoire. Un wa soutenu signifie latence/queueing de stockage.

Décision : Swap élevé : corriger la mémoire (réduire le working set, ajouter de la RAM, ajuster les caches). Iowait élevé : mesurer la latence disque et trouver le périphérique ou le montage responsable.

Tâche 6 : Mesurer la latence et l’utilisation disque par périphérique (le sérum de vérité)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0-41-generic (server)  12/29/2025  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          19.20    0.00    7.10   28.40    0.00   45.30

Device            r/s     w/s   rKB/s   wKB/s  await  aqu-sz  %util
nvme0n1         120.0   310.0  6400.0 41000.0  18.40    6.20  98.00
sda               0.0     2.0     0.0    48.0   1.10    0.01   0.20

Signification : await est la latence moyenne d’E/S. aqu-sz et %util montrent l’encombrement et la saturation. Un périphérique à ~98% util avec un await croissant est un goulot.

Décision : Si le disque principal est saturé, trouvez qui lit/écrit et si c’est attendu (charge DB) ou nouveau (storm de logs, snap refresh, indexation, agent de backup).

Tâche 7 : Attribuer les E/S disque aux processus (qui martèle le disque)

cr0x@server:~$ sudo iotop -oPa
Total DISK READ: 28.40 M/s | Total DISK WRITE: 41.10 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
  982 be/4  syslog      0.00 B/s   9.50 M/s  0.00 % 95.00% systemd-journald
 1777 be/4  root        0.00 B/s   7.20 M/s  0.00 % 80.00% snapd
 2143 be/4  app         6.10 M/s   2.40 M/s  0.00 % 35.00% node /srv/app/server.js

Signification : Vous voyez quels processus font de l’I/O réelle maintenant. Un IO> élevé suggère que le processus passe du temps en attente d’E/S plutôt qu’à exécuter du code.

Décision : Si journald écrit beaucoup, inspectez le taux de logs et les paramètres de persistance. Si snapd écrit beaucoup pendant refresh/seeding, planifiez ou contrôlez les fenêtres de refresh.

Tâche 8 : Vérifier la taille et le taux de journald (les tempêtes de logs sont des tempêtes de performance)

cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 6.2G in the file system.
cr0x@server:~$ sudo journalctl -p warning -S "1 hour ago" | tail -n 8
Dec 29 09:12:41 server kernel: nvme nvme0: I/O 123 QID 7 timeout, aborting
Dec 29 09:12:43 server kernel: nvme nvme0: Controller reset, clearing queue
Dec 29 09:12:44 server systemd-journald[982]: Missed 312 log messages due to rate-limiting

Signification : De gros journaux ne sont pas automatiquement mauvais, mais une forte churn l’est. De plus, les warnings de timeouts de périphérique se corrèlent fortement avec des pics de latence.

Décision : Si vous voyez des timeouts/resets de stockage, vous êtes en territoire pilote/firmware. Si journald est énorme et croît rapidement, rate-limitez les services bruyants et définissez une rétention raisonnable.

Tâche 9 : Inspecter le ring buffer du noyau pour erreurs stockage et réseau

cr0x@server:~$ dmesg -T | egrep -i "nvme|reset|timeout|error|ext4|xfs|zfs|link is down|iommu" | tail -n 25
[Mon Dec 29 09:12:41 2025] nvme nvme0: I/O 123 QID 7 timeout, aborting
[Mon Dec 29 09:12:43 2025] nvme nvme0: Controller reset, clearing queue
[Mon Dec 29 09:12:44 2025] EXT4-fs (nvme0n1p2): warning: mounting fs with errors, running e2fsck is recommended
[Mon Dec 29 09:13:02 2025] igb 0000:03:00.0 eno1: Link is Down

Signification : Les timeouts et resets ne sont pas du « bruit ». Ce sont des tueurs de performance car ils déclenchent des retries, des vidages de file et des blocages applicatifs. Les warnings de système de fichiers peuvent engendrer du travail de journalisation supplémentaire.

Décision : Erreurs de stockage : arrêtez de tuner et commencez à stabiliser (firmware, câblage, BIOS, régression noyau). Link flaps réseau : vérifiez le pilote/firmware NIC et le port du switch.

Tâche 10 : Valider la fréquence CPU et le gouverneur (la lenteur silencieuse)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
cr0x@server:~$ grep -E "model name|cpu MHz" /proc/cpuinfo | head -n 6
model name	: Intel(R) Xeon(R) Silver 4314 CPU @ 2.40GHz
cpu MHz		: 800.028
model name	: Intel(R) Xeon(R) Silver 4314 CPU @ 2.40GHz
cpu MHz		: 800.031

Signification : Si vous êtes bloqué à ~800 MHz sous charge, vous n’avez pas « une mauvaise journée », vous êtes limité par l’alimentation. Les mises à jour peuvent changer le comportement d’un daemon de gestion d’alimentation sur certaines configurations ou révéler des contraintes BIOS.

Décision : Sur les serveurs, vous voulez généralement des performances prévisibles : définissez le gouverneur de façon appropriée (souvent performance) ou utilisez un profil tuned qui correspond à vos SLO.

Tâche 11 : Voir si la pression mémoire est réelle (reclaim, swap et risques OOM)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi        49Gi       1.2Gi       1.1Gi        12Gi       6.8Gi
Swap:          8.0Gi       2.4Gi       5.6Gi
cr0x@server:~$ cat /proc/pressure/memory
some avg10=0.25 avg60=0.18 avg300=0.12 total=92841712
full avg10=0.03 avg60=0.01 avg300=0.01 total=3812233

Signification : Un faible « available » et du swap utilisé peuvent être acceptables selon la charge, mais PSI (/proc/pressure) vous indique si des tâches attendent la mémoire. Une pression full > 0 suggère une contention sérieuse.

Décision : Si la PSI mémoire monte pendant les incidents, ajustez l’usage mémoire, limitez les services incontrôlés ou ajoutez de la RAM. Si le swap thrash, réduisez swappiness ou corrigez la charge.

Tâche 12 : Chercher des limites cgroup ou des changements de conteneurs après mise à jour

cr0x@server:~$ systemctl status docker --no-pager | sed -n '1,12p'
● docker.service - Docker Application Container Engine
     Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-12-29 02:16:12 UTC; 7h ago
cr0x@server:~$ cat /sys/fs/cgroup/cgroup.controllers
cpuset cpu io memory hugetlb pids rdma misc

Signification : Ubuntu 24.04 utilise cgroup v2 par défaut dans les configurations courantes. Les mises à jour changent parfois les hypothèses du runtime de conteneur. Une application peut devenir CPU-throttled ou limitée en I/O par une politique cgroup, ce qui ressemble à « l’hôte est OK mais l’appli est lente ».

Décision : Si vous exécutez des conteneurs, vérifiez les contraintes de ressources et les versions du runtime. Corrigez la limite plutôt que de tuner bêtement l’hôte.

Tâche 13 : Vérifier les options de montage et la santé du système de fichiers (surtout après des changements noyau)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /
/dev/nvme0n1p2 / ext4 rw,relatime,errors=remount-ro
cr0x@server:~$ sudo tune2fs -l /dev/nvme0n1p2 | egrep -i "Filesystem state|Errors behavior|Default mount options"
Filesystem state:         clean
Errors behavior:          Remount read-only
Default mount options:    user_xattr acl

Signification : Vous confirmez quel système de fichiers est utilisé et comment il est monté. Si des erreurs ont été détectées, ext4 peut faire du travail supplémentaire ou remonter en lecture seule.

Décision : Si le système de fichiers rapporte des erreurs ou que le noyau a logué des warnings, planifiez une fenêtre de maintenance pour fsck et examinez la stabilité du stockage. N’« optimisez » pas un disque défectueux.

Tâche 14 : Vérifier rapidement le chemin réseau (parce que la latence peut se faire passer pour un problème CPU)

cr0x@server:~$ ip -s link show eno1 | sed -n '1,12p'
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    918273645  821933     12      98       0    1203
    TX:  bytes packets errors dropped carrier collsns
    827364554  801102      0       0       7       0
cr0x@server:~$ ss -s
Total: 1048 (kernel 0)
TCP:   812 (estab 621, closed 134, orphaned 0, synrecv 0, timewait 134/0), ports 0
Transport Total     IP        IPv6
RAW       0         0         0
UDP       18        12        6

Signification : Les erreurs RX/TX et les problèmes de carrier peuvent ralentir les performances ou créer des tempêtes de retries. ss -s donne un aperçu rapide de l’état des sockets.

Décision : Si les erreurs ont augmenté après une mise à jour, suspectez une régression pilote/firmware ou des changements d’offload. Vérifiez avec les compteurs du switch et envisagez de pinner/rollback le pilote NIC si nécessaire.

Faits & contexte intéressants (pourquoi ça revient)

Les mises à jour du noyau changent plus que « le noyau ». Elles livrent de nouveaux pilotes de périphériques, des ajustements de scheduler, des comportements de la pile bloc, et parfois de nouveaux paramètres par défaut. Les chemins stockage et NIC sont particulièrement sensibles.
Les ordonnanceurs I/O Linux ont beaucoup évolué. Les noyaux modernes choisissent souvent mq-deadline ou none pour NVMe ; les anciens guides recommandant CFQ sont des artefacts d’une ère différente.
La gestion d’alimentation NVMe a une longue histoire de surprises. Des fonctionnalités comme APST peuvent être excellentes pour la consommation, mais des bizarreries firmware peuvent causer des pics de latence ou des resets sur certains matériels.
systemd a graduellement absorbé des responsabilités autrefois gérées par des démons séparés. C’est positif pour la cohérence, mais cela signifie que des changements systemd/journald peuvent se traduire par des comportements de performance après des mises à jour.
« iowait » n’est pas une mesure de la vitesse du disque. C’est du temps CPU passé à attendre la complétion d’E/S. C’est un symptôme indiquant qu’un flux est bloqué, pas une cause racine en soi.
cgroup v2 est maintenant le défaut dans beaucoup de distributions mainstream. Il améliore le contrôle des ressources, mais les upgrades peuvent exposer du throttling auparavant caché ou des limites mal réglées, surtout dans des environnements conteneurisés.
Le modèle transactionnel de Snap échange un peu d’I/O contre de la fiabilité. C’est un choix de conception délibéré : plus de métadonnées et plus d’écritures pendant les mises à jour, souvent visible sur des disques occupés ou petits.
Les systèmes de fichiers journalisés privilégient la cohérence. ext4 et XFS visent à survivre aux crashs, mais certaines charges et une journalisation intensive peuvent rendre le comportement de commit visible en latence.
Les mises à jour microcode peuvent modifier le profil de performance. Elles corrigent des failles de sécurité et de stabilité réelles, mais peuvent aussi changer le comportement de boost ou atténuer des errata CPU d’une manière qui affecte la latence tail.

Trois mini-récits d’entreprise venus des opérations

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’entreprise était en migration vers Ubuntu 24.04, et la première vague semblait correcte. Puis un cluster de nœuds « identiques » a commencé à timeout sous charge modérée juste après la fenêtre de patch prévue. L’équipe a supposé que c’était la release applicative — parce que les releases applicatives sont toujours coupables jusqu’à preuve du contraire. Ils ont lancé un rollback. Rien ne s’est amélioré.

Les graphiques montraient que les hôtes n’étaient pas saturés CPU. La mémoire était confortable. Mais la latence tail était détruite. Les logs étaient pleins d’avertissements apparemment bénins que personne n’avait le temps de lire. Ils ont fait ce que font les équipes sous stress : ajouté des réplicas. Ça a empiré, parce que le système est devenu plus parallèle en I/O et a poussé le périphérique de stockage dans un enfoncement de queues plus profond.

L’hypothèse erronée était subtile : « Tous les NVMe se comportent pareil. » Ces nœuds avaient un modèle NVMe différent à cause d’un remplacement dans la chaîne d’approvisionnement. Le nouveau noyau a activé un chemin de gestion d’alimentation que l’ancien noyau ne sollicitait pas. Sous certains patterns d’accès, le firmware du disque réinitialisait le contrôleur. Chaque reset causait des secondes d’E/S bloquées, et chaque E/S bloquée se transformait en timeouts applicatifs.

La correction n’a pas été héroïque. Ils ont pigné un noyau connu bon pour ce cohort matériel, désactivé le réglage d’économie d’énergie problématique du NVMe, et planifié une validation firmware. La leçon : variance matérielle + changement de noyau = « lisez dmesg avant de toucher l’appli ».

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre équipe a vu les écritures disque exploser après la montée de version d’une flotte. Ils ont constaté que journald avait grossi et ont décidé « d’optimiser » en plaçant le journal sur le périphérique le plus rapide et en augmentant la rétention « pour mieux déboguer ». Ça semblait raisonnable et a même eu un pouce en l’air dans le chat.

Une semaine plus tard, le périphérique le plus rapide était devenu le plus occupé. Leur base de données partageait ce même NVMe. Pendant les heures de pointe, la latence a augmenté et les requêtes p99 sont devenues horribles. La base n’était pas en panne de débit ; elle perdait la loterie de la latence parce que la journalisation était devenue un écrivain de fond constant avec des points de sync.

Le retour de bâton n’était pas journald en soi — c’était la combinaison d’un volume de logs plus élevé d’un service devenu verbeux, d’une rétention plus longue et d’une colocation avec du stockage sensible à la latence. Ils avaient optimisé pour la « localité I/O » et obtenu « contention I/O ».

La correction a été ennuyeuse : limiter la taille du journal, réduire la verbosité du service bavard, et envoyer les logs volumineux hors hôte de façon asynchrone. Ils ont aussi séparé « rapide » de « critique ». Un stockage rapide n’est pas une poubelle infinie ; c’est l’endroit pour la charge qui ne peut tolérer la mise en queue.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation avait une règle : chaque fenêtre de patch produisait un « change record » avec trois artefacts — version du noyau, top 20 des paquets modifiés, et un snapshot de 10 minutes des compteurs de performance baseline (CPU, PSI mémoire, latence iostat, erreurs réseau). Ce n’était pas glamour. Personne n’a été promu pour ça. Mais ça raccourcissait les incidents.

Après une mise à jour, un ensemble de serveurs API a ralenti. L’astreinte a extrait le baseline précédent de la dernière fenêtre de patch et a immédiatement vu un nouveau motif : la fréquence CPU était plus basse sous charge et le switching de contexte était plus élevé. La latence disque était inchangée, le réseau propre. La classe de goulot était le comportement CPU, pas le stockage.

La cause racine était un changement de profil d’alimentation après une mise à jour de package non liée. Ils n’ont pas passé des heures à blâmer le noyau ou à chasser des E/S fantômes. Ils ont restauré le profil de performance, vérifié l’échelle de fréquence sous charge, et clos l’incident avant que le business ne l’escalade.

C’est le genre de pratique qui ressemble à de la paperasserie jusqu’au jour où elle vous sauve : capturez un baseline quand le système est sain. Sinon vous passerez votre temps à vous disputer avec votre mémoire, qui n’est pas un outil de monitoring fiable.

Erreurs courantes : symptôme → cause racine → correction

Ce sont les schémas que je vois répétitivement après les mises à jour Ubuntu, y compris 24.04. Les symptômes sont ce que les gens rapportent. La cause racine est ce qui se passe réellement. La correction est spécifique et testable.

1) « La charge est élevée mais l’utilisation CPU est faible »

Symptôme : Moyenne de charge en hausse ; top montre des CPUs principalement inactifs ; les applis bloquent.
Cause racine : Threads bloqués en sommeil I/O uninterruptible (latence stockage ou resets de pilote).
Correction : Lancez iostat -xz et dmesg -T. Si vous voyez des timeouts/resets NVMe, stabilisez firmware/paramètres noyau ; si la latence est réelle, trouvez le writer avec iotop.

2) « Tout est plus lent après le reboot, mais ça s’améliore progressivement »

Symptôme : Première heure après redémarrage terrible ; plus tard supportable.
Cause racine : Tâches post-update : snap seeding/refresh, rebuild de caches, updatedb, génération de packs de langue, scan d’images de conteneur.
Correction : Utilisez systemd-analyze blame, journalctl et iotop pour identifier la churn. Reprogrammez ou limitez ces tâches. Ne faites pas de benchmark pendant le « premier boot après mise à jour ».

3) « Le débit disque semble correct, mais l’appli timeout »

Symptôme : MB/s élevé ; dashboards affichent un bon débit ; la latence p99 explose.
Cause racine : Latence et queueing, pas le débit. Mélange de reads/writes et logging sync-heavy peuvent provoquer de longues latences tail.
Correction : Concentrez-vous sur await, aqu-sz et l’I/O par processus. Réduisez la fréquence des sync, séparez les écrivains bruyants, et validez les options de montage du système de fichiers.

4) « Le CPU n’est qu’à 30% mais les requêtes sont lentes »

Symptôme : Beaucoup de marge ; pourtant lent.
Cause racine : CPU coincé à basse fréquence (gouverneur/profil d’alimentation) ou throttling via des limites cgroup.
Correction : Vérifiez scaling_governor et la valeur CPU MHz ; contrôlez les limites de conteneurs ; corrigez le profil d’alimentation ou la politique cgroup.

5) « Après la mise à jour, le disque est constamment occupé à faire ‘rien’ »

Symptôme : Forte utilisation disque à l’idle ; ventilateurs qui s’emballent ; le shell interactif traîne.
Cause racine : Croissance de journald, tempêtes de logs, snap refresh, ou un scanner/indexeur nouvellement activé.
Correction : Identifiez le writer avec iotop. Rate-limitez la source bruyante, calez la taille du journal, et gérez les fenêtres de snap refresh.

6) « Le réseau est devenu instable et maintenant les performances sont catastrophiques »

Symptôme : Retries, appels API lents, timeouts intermittents.
Cause racine : Régression pilote, changement d’options d’offload, link flaps, ou mismatch MTU après mise à jour.
Correction : Inspectez ip -s link pour les erreurs et les messages dmesg de link ; coordonnez-vous avec les compteurs réseau ; n’ajustez les offloads qu’avec des preuves.

Blague #2 : Les régressions noyau sont comme les machines à café du bureau : dès que vous dépendez d’elles, elles développent du « caractère ».

Listes de contrôle / plan pas à pas

Checklist A : Triage en 10 minutes sur un hôte seul

Enregistrez le noyau et l’uptime (uname -a, uptime -s).
Vérifiez les mises à jour récentes (/var/log/dpkg.log tail).
Vérifiez les services échoués et le blame au boot (systemctl --failed, systemd-analyze blame).
Classez avec vmstat 1 (surveillez wa, si, so).
Mesurez la latence disque avec iostat -xz.
Attribuez l’I/O avec iotop -oPa si le disque est chaud.
Vérifiez les logs noyau pour resets/timeouts (dmesg -T filtré).
Vérifiez le gouverneur CPU et la fréquence (scaling_governor, /proc/cpuinfo).
Vérifiez la PSI mémoire (/proc/pressure/memory) et l’usage swap (free -h).
Prenez une décision : atténuer (stopper l’offender), rollback du noyau, ou ouvrir une enquête matériel/driver.

Checklist B : Quand c’est un problème de flotte (pas un host)

Choisissez trois hôtes : un rapide, un lent, un moyen.
Comparez les versions du noyau et les packages microcode.
Comparez les IDs matériel (modèle NVMe, modèle NIC) pour ne pas chasser un « logiciel » qui est en fait du matériel.
Comparez latence iostat et erreurs dmesg entre cohortes.
Si cela se corrèle à un build noyau spécifique, envisagez de pinner ou rollback ce noyau sur le matériel affecté.
Confirmez si de nouveaux services sont activés sur les hôtes lents (systemctl list-unit-files --state=enabled diff).

Checklist C : Actions de mitigation contrôlées (faites celles-ci, pas du tuning au hasard)

Si le disque est saturé par les logs : réduire la verbosité, limiter la taille du journal, déplacer les logs volumineux hors-hôte de façon asynchrone.
Si snap refresh perturbe les SLO : planifier des fenêtres de refresh et éviter le seeding pendant les pics.
Si des resets NVMe apparaissent : prioriser la validation firmware et les mitigations paramètres noyau plutôt que du « tuning système de fichiers ».
Si la fréquence CPU est bloquée : corriger le gouverneur/profil et confirmer sous charge avec des tests répétables.
Si la PSI mémoire est élevée : réduire le working set, corriger les fuites, fixer des limites ou ajouter de la RAM — puis re-mesurer.

FAQ

1) Comment savoir si la lenteur vient du CPU, du disque ou de la mémoire ?

Utilisez vmstat 1 et iostat -xz. Un wa élevé + un await élevé pointe vers la latence disque. L’activité de swap et la PSI mémoire pointent vers une pression mémoire. Un CPU utilisateur/système élevé avec un iowait bas pointe vers le CPU ou un overhead d’appels système.

2) La mise à jour est terminée, mais je n’ai pas redémarré. Les performances peuvent-elles changer quand même ?

Oui. Les services en espace utilisateur peuvent redémarrer, la configuration peut changer, et des tâches en arrière-plan (snap refreshes, rebuild de cache) peuvent démarrer immédiatement. Le comportement noyau/pilote change généralement après redémarrage, mais toutes les régressions n’en dépendent pas.

3) Pourquoi iowait compte-t-il autant si le CPU semble inactif ?

Parce que vos threads applicatifs attendent le stockage. Les CPUs inactifs n’aident pas si le chemin de requête est bloqué sur fsync, des écritures metadata ou des retries de périphérique. Mesurez la latence disque, pas seulement l’utilisation.

4) Dois-je rollback le noyau immédiatement ?

Si vous avez des preuves claires de resets/timeouts de pilote ou une régression corrélée à un noyau sur une cohorte, rollbacker est une mesure de confinement raisonnable. Si le goulot est un service bruyant ou de la journalisation, rollback ne vous aidera pas et fera perdre du temps.

5) Snapd est occupé après la mise à jour — dois-je supprimer les snaps ?

Pas en réaction réflexe. Confirmez d’abord que snapd est le coupable avec iotop et systemd-analyze blame. Ensuite, contrôlez les fenêtres de refresh et évitez les conflits avec des charges sensibles à la latence. Supprimer les snaps peut accroître la surface opérationnelle plus qu’elle ne sauve.

6) Quel est le moyen le plus rapide pour détecter des problèmes NVMe ?

dmesg -T filtré sur nvme, timeout et reset, plus iostat -xz pour des pics de latence. Si vous voyez des resets de contrôleur, arrêtez de tuner le système de fichiers et commencez à valider firmware et comportement noyau.

7) Comment les denials AppArmor se manifestent-ils comme des problèmes de performance ?

Les denials peuvent forcer des repliements, des échecs répétés ou des retries dans des chemins chauds. Vérifiez journalctl pour les messages AppArmor et corrélez les horodatages avec la latence. La correction est généralement un ajustement de la politique ou la correction des chemins d’accès attendus par le service — pas une désactivation large d’AppArmor.

8) Est-il sûr de régler le gouverneur CPU en performance sur des serveurs Ubuntu 24.04 ?

Souvent oui pour des environnements sensibles à la latence, si la puissance et le refroidissement sont dimensionnés correctement. Mais traitez cela comme un changement : appliquez-le à un sous-ensemble, mesurez, et confirmez que vous ne déclenchez pas de throttling thermique ou ne violez pas des budgets d’alimentation.

9) Pourquoi journald devient-il parfois un goulot ?

Une journalisation à haut volume consiste en de nombreuses petites écritures soutenues et des mises à jour metadata. Si un service devient bruyant après une mise à jour, journald peut créer une pression d’écriture constante et des points de sync. Limitez la taille, réduisez la verbosité et n’hébergez pas la churn de logs sur votre stockage le plus sensible à la latence si vous pouvez l’éviter.

Prochaines étapes pratiques

Faites ceci aujourd’hui, pendant que l’incident est encore frais et que les preuves n’ont pas disparu des logs :

Exécutez le playbook de diagnostic rapide sur un hôte affecté et un hôte non affecté. Notez : noyau, latence iostat, process I/O principal, et tout dmesg d’erreur.
Si vous voyez des timeouts/resets de périphérique : contenir le rayon d’action (pinner/rollback du noyau sur le cohort matériel affecté) et ouvrir une enquête firmware/driver.
Si vous voyez churn I/O lié aux logs ou snap : limitez-le, planifiez-le ou déplacez-le. Ne laissez pas la maintenance de fond concurrencer vos SLOs de premier plan.
Si la fréquence CPU est incorrecte : corrigez le gouverneur/profil et vérifiez sous charge avec des mesures répétables, pas à l’intuition.
Capturez un artifact baseline après stabilisation. La prochaine fenêtre de patch, vous me remercierez.