Proxmox ralenti après une mise à jour : les premières vérifications qui révèlent généralement la cause

Feuille de route de diagnostic rapide (première/deuxième/troisième)

Si vous avez une heure pour arrêter l’hémorragie, faites ceci. N’ouvrez pas vingt terriers de lapin. Choisissez d’abord le goulot d’étranglement de plus haut niveau, puis approfondissez.

Première étape : identifiez quelle ressource est saturée maintenant

• CPU hôte : vérifiez la charge par rapport à l’utilisation CPU et au temps de steal. Une charge élevée avec une faible utilisation CPU crie « attente I/O » ou contention de verrous.
• I/O hôte : vérifiez la latence disque et la profondeur de file d’attente. Un peu de latence est acceptable ; des dizaines de millisecondes soutenues sur des I/O aléatoires sont un crime de performance.
• Réseau : vérifiez les pertes, erreurs et incohérences de MTU/offloads. Une perte de paquets discrète, c’est « ça marche en dev » pour la production.

Deuxième étape : décidez si le problème est global à l’hôte ou spécifique à une VM

• Si toutes les VMs ont ralenti de la même façon après la mise à jour, suspectez le noyau de l’hôte, le backend de stockage, le pilote NIC/offload, ou les services de cluster.
• Si seule une partie a ralenti, suspectez des paramètres matériels VM spécifiques (virtio/scsi controller, cache mode), des pilotes invités, ou des limites par VM.

Troisième étape : comparez « avant vs après » avec la base la plus simple

• Exécutez un micro-test I/O depuis l’hôte (avec précaution) pour voir si le sous-système de stockage a régressé.
• Effectuez un contrôle de sanity CPU et I/O depuis une VM unique pour confirmer que la frontière hyperviseur n’est pas le coupable.
• Vérifiez si la mise à jour a modifié le noyau, les versions ZFS/Ceph, l’ordonnanceur IO, ou les valeurs par défaut de QEMU.

Règle empirique : si vous ne pouvez pointer vers un seul élément parmi CPU, I/O, ou réseau comme « dominant » dans les 15 premières minutes, vous ne regardez pas les bons compteurs.

Ce que les mises à jour changent (et pourquoi c’est important)

Les mises à jour Proxmox sont trompeusement « un clic ». Sous ce clic : un nouveau noyau, QEMU mis à jour, piles de stockage mises à jour (ZFS, clients/daemons Ceph si vous les exécutez), nouveaux pilotes NIC, nouveaux paramètres par défaut, et parfois de nouveaux comportements autour des cgroups, de l’ordonnancement et de la gestion d’alimentation.

Les régressions de performance après mises à jour tombent typiquement dans ces catégories :

• Changements noyau/driver : changement d’ordonnanceur I/O par défaut, comportement d’offload NIC, gestion des IRQ, governor de fréquence CPU, ou une régression de pilote.
• Changements de la pile de stockage : changements de version ZFS affectant le comportement de l’ARC ou le traitement des écritures sync ; mises à jour Ceph modifiant le comportement de recovery/backfill.
• Dérive de la configuration matérielle VM : types de contrôleurs, modes de cache, iothreads, ballooning, ou changements de modèle CPU.
• Services de cluster : sensibilité de corosync à la latence, problèmes de synchronisation temporelle, ou comportement « utile » du watchdog.
• Travail d’arrière-plan nouveau : scrubs/resilvers, rebalancing Ceph, scans SMART, pvestatd qui poll, tempêtes de logs.

Les mises à jour exposent aussi les fautes existantes. Votre plateforme a peut-être survécu grâce à un cache favorable, une sous-utilisation discrète, ou une bizarrerie de pilote qui s’est avérée bénéfique. Les mises à jour retirent cette chance.

Une citation à garder :

« L’espoir n’est pas une stratégie. » — James Cameron

Cela s’applique aussi aux mises à jour : traitez-les comme de la gestion du changement, pas comme un feeling.

Faits intéressants et contexte historique

1. KVM est arrivé dans Linux en 2007, et il a gagné en grande partie parce que c’était « juste » le noyau Linux qui faisait la virtualisation, pas un hyperviseur séparé.
2. Virtio a été conçu pour éviter d’émuler du matériel legacy lent. Quand les pilotes virtio manquent ou sont incompatibles, on peut observer des différences de 10× sur le débit stockage et NIC.
3. ZFS est arrivé sur Linux via un port (OpenZFS), et il est célèbre pour l’intégrité des données — mais aussi pour sa sensibilité à la RAM, aux schémas d’écriture sync et aux jeux de données mal configurés.
4. La performance de Ceph peut sembler « correcte » alors qu’il est en mauvaise santé parce qu’il continue de servir des IO tout en effectuant silencieusement recovery et backfill en arrière-plan.
5. Linux a migré de nombreux systèmes vers cgroup v2 par défaut ; changements d’ordonnancement et de comptabilité peuvent affecter subtilement des hôtes Proxmox très orientés conteneurs.
6. Les NVMe modernes sont rapides mais pas magiquement homogènes : firmware, états d’alimentation et throttling thermique peuvent créer des patterns de latence en « dents de scie » après des redémarrages.
7. Les ordonnanceurs I/O ont changé de philosophie : pour les dispositifs rapides, « none » gagne souvent ; pour des disques plus lents, des ordonnanceurs qui fusionnent les requêtes peuvent réduire les pics de latence.
8. La mise à l’échelle de fréquence CPU est une variable de performance, pas une case verte. Un autre paramètre par défaut du noyau peut vous faire passer d’un comportement prévisible à un comportement lent sous charge éclatée.
9. Corosync dépend d’une livraison réseau ponctuelle. Une petite augmentation de latence/jitter peut provoquer des flaps de membership, qui ressemblent à une « lenteur aléatoire » ailleurs.

Partir des premiers principes : définir correctement « plus lent »

« Plus lent » est une plainte. Il vous faut un symptôme mesurable.

Choisissez une ou deux charges représentatives et définissez la régression en chiffres :

• Base de données : latence de commit au 95e percentile, taux de hit du buffer cache, temps de fsync.
• Web/API : percentiles de latence des requêtes, taux d’erreur, saturation CPU, file d’exécution.
• Serveur de fichiers : débit SMB/NFS, latence des opérations de métadonnées, création de petits fichiers.
• Sauvegardes : MB/s et temps écoulé, plus la latence d’écriture du stockage pendant les fenêtres de sauvegarde.

Puis déterminez où a lieu l’attente. La plupart du temps c’est l’un de ces cas :

• Attente I/O sur l’hôte : pics de latence stockage, files d’attente qui s’accumulent, VMs bloquées.
• Délai d’ordonnancement CPU : trop de tâches exécutables, erreurs de pinning, tempêtes d’IRQ.
• Perte/jitter réseau : retransmissions et timeouts, corosync grincheux, réplication de stockage ralentie.
• Mauvaise adéquation des pilotes invités : pilotes virtio obsolètes, mauvais modèle de contrôleur, modes de cache étranges.

Blague #1 : Les régressions de performance sont comme « encore une réunion » — personne ne les planifie, mais tout le monde y assiste.

Tâches pratiques : commandes, sorties et décisions

Voici les premières vérifications que j’exécute sur un hôte Proxmox après une mise à jour quand on me dit « c’est plus lent ». Chaque tâche inclut : commande, ce qui est bon/mauvais, et quelle décision prendre.

Task 1: Confirm what actually changed (kernel, pve, qemu)

cr0x@server:~$ pveversion -v
pve-manager/8.2.2/bb2d... (running kernel: 6.8.12-3-pve)
proxmox-ve: 8.2-1 (running kernel: 6.8.12-3-pve)
qemu-server/8.2.4/...
libpve-storage-perl/8.2.2/...

Signification : Vous connaissez maintenant les versions de noyau et de la pile en jeu. « C’est plus lent » se traduit souvent par « le noyau a changé » ou « QEMU a changé ».

Décision : Si la régression a commencé exactement après cela, priorisez les vérifications noyau/driver/stockage avant de chasser l’optimisation spécifique VM.

Task 2: Check if the host is CPU-bound, I/O-bound, or just confused

cr0x@server:~$ uptime
 14:02:11 up 12 days,  3:45,  3 users,  load average: 18.21, 16.77, 15.90

Signification : La load average compte les tâches exécutables et les tâches en sommeil ininterruptible (souvent I/O). Une load élevée ne signifie pas automatiquement un CPU élevé.

Décision : Associez ceci à l’utilisation par CPU et à l’iowait ensuite. Si la load est élevée mais l’utilisation CPU modeste, suspectez la latence de stockage ou la contention de verrous du noyau.

Task 3: Look for iowait and steal time on the host

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.12-3-pve (server)  12/26/2025  _x86_64_  (32 CPU)

Average:     CPU   %usr   %nice    %sys %iowait   %irq  %soft  %steal  %idle
Average:     all   12.40    0.00    4.10   18.70   0.00   0.80    0.00  64.00
Average:       0   10.00    0.00    3.00   22.00   0.00   0.50    0.00  64.50

Signification : Un %iowait soutenu dans les dizaines signifie que le CPU attend le stockage. %steal est typiquement 0 sur du bare metal, mais compte en virtualisation imbriquée.

Décision : Si l’iowait est élevé, cessez de « tuner le CPU ». Passez immédiatement aux vérifications de latence et profondeur de file du stockage.

Task 4: Identify the top processes and whether they are blocked on IO

cr0x@server:~$ top -b -n 1 | head -25
top - 14:02:33 up 12 days,  3:45,  3 users,  load average: 18.21, 16.77, 15.90
Tasks: 812 total,   5 running, 807 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.3 us,  4.1 sy,  0.0 ni, 64.0 id, 18.7 wa,  0.0 hi,  0.9 si,  0.0 st
MiB Mem : 256000.0 total,  84000.0 free,  42000.0 used, 130000.0 buff/cache
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
8421 root      20   0 11.8g   2.1g  10500 S  180.0  0.8  90:12.22 kvm
9211 root      20   0 10.2g   1.9g   9700 D   40.0  0.7  15:44.01 kvm

Signification : L’état D signifie sommeil ininterruptible — souvent bloqué sur I/O. Voir des threads KVM en état D est un indicateur classique « le stockage bloque les VMs ».

Décision : Passez aux vérifications de latence au niveau du périphérique (iostat, nvme smart-log, santé ZFS/Ceph) avant de toucher aux configs VM.

Task 5: Measure disk latency and queueing per device

cr0x@server:~$ iostat -x 1 5
Linux 6.8.12-3-pve (server)  12/26/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.35    0.00    4.12   18.69    0.00   64.84

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         120.0  980.0   4200.0 128000.0    240.0     9.80    9.60     2.10    10.50   0.35  38.0
sda               2.0   80.0     40.0   1800.0     46.0     3.20   45.00     8.00    46.00   1.20  95.0

Signification : Regardez await et avgqu-sz. Un périphérique lent avec une forte utilisation et un await élevé (comme sda ci-dessus) peut ralentir tout le chemin de stockage s’il fait partie du pool/array ou sert pour les logs.

Décision : Si un périphérique est bloqué à forte %util avec un grand await, identifiez son usage (vdev spécial ZFS ? disque de boot ? Ceph WAL/DB ?) et corrigez ce chemin.

Task 6: Confirm ZFS pool health and whether it’s doing background work

cr0x@server:~$ zpool status -v
  pool: rpool
 state: ONLINE
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
 scan: resilver in progress since Thu Dec 26 12:11:09 2025
        1.22T scanned at 1.80G/s, 220G issued at 320M/s, 3.45T total
        220G resilvered, 6.2% done, 02:45:12 to go
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            nvme0n1 ONLINE       0     0     0
            nvme1n1 ONLINE       0     0     0

Signification : Un resilver ou scrub peut marteler les I/O. Après une mise à jour/reboot, ces tâches peuvent démarrer ou reprendre.

Décision : Si vous êtes en urgence de performance, planifiez scrubs/resilvers de façon réfléchie (pas « jamais »), et réduisez les charges concurrentes pendant les fenêtres de récupération.

Task 7: Check ZFS dataset properties that impact latency (sync, compression, recordsize)

cr0x@server:~$ zfs get -o name,property,value -s local,received sync,compression,recordsize,logbias,primarycache rpool/data
NAME        PROPERTY     VALUE
rpool/data  sync         standard
rpool/data  compression  zstd
rpool/data  recordsize   128K
rpool/data  logbias      latency
rpool/data  primarycache all

Signification : Les mises à jour ne changent pas habituellement ces valeurs par elles-mêmes, mais des migrations et des « réglages utiles » le font parfois. sync et logbias sont des leviers de latence pour les charges sync-intensives.

Décision : Si vous voyez sync=always de façon inattendue, attendez-vous à des bases de données plus lentes. Corrigez la cause racine (exports NFS ? héritage de dataset ?) plutôt que de désactiver aveuglément sync.

Task 8: Observe ZFS ARC pressure (memory vs cache behavior)

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  size     c
14:03:51   812   120     14    28    3    70    8    22    3  96.1G  108G
14:03:52   790   140     17    31    4    81   10    28    4  95.9G  108G
14:03:53   840   160     19    35    4    91   11    34    4  95.8G  108G

Signification : Une miss% croissante et un ARC qui diminue peuvent pousser plus de lectures vers le disque. Après des mises à jour, les motifs de pression mémoire peuvent changer (conteneurs, services, usage mémoire noyau).

Décision : Si l’ARC est constamment comprimé, validez l’allocation RAM hôte, le ballooning, et si de nouveaux services (par ex. des daemons Ceph) concurrencent la mémoire.

Task 9: Confirm Ceph health and whether it’s recovering/rebalancing

cr0x@server:~$ ceph -s
  cluster:
    id:     9e2a...c6
    health: HEALTH_WARN
            1 osds down
            Degraded data redundancy: 24/1024 objects degraded
            Reduced data availability: 8 pgs inactive
  services:
    mon: 3 daemons, quorum pve1,pve2,pve3
    mgr: pve1(active), standbys: pve2
    osd: 11 osds: 10 up, 11 in
  data:
    pools:   4 pools, 256 pgs
    objects: 1.2M objects, 4.1 TiB
    usage:   12 TiB used, 24 TiB / 36 TiB avail
    pgs:     8 inactive, 24 degraded
  io:
    client:   220 MiB/s rd, 45 MiB/s wr, 1.8k op/s rd, 0.6k op/s wr

Signification : Un état « WARN » avec des PGs dégradés et de la recovery signifie que les IO clients concourent avec les IO de recovery. La performance sera inconstante.

Décision : Réparez d’abord la santé. Tenter de tuner un Ceph malade revient à réarranger les chaises pendant des turbulences.

Task 10: Check if recovery/backfill is consuming the cluster

cr0x@server:~$ ceph tell 'osd.*' perf dump | head
{
    "filestore": {
        "journal_queue_max_ops": 500,
        "op_queue_max_ops": 1000
    },
    "throttle-msgr_dispatch_throttler": {
        "val": 0
    }
}

Signification : C’est un aperçu rudimentaire. En pratique vous regarderez les taux de recovery, le backfill, et les compteurs perf des OSD pour voir si le cluster est occupé à « se réparer ».

Décision : Si la recovery est lourde et que l’entreprise a besoin de performance maintenant, ajustez temporairement les paramètres de recovery (avec précaution) et planifiez les réparations. Mais ne laissez pas ces réglages en production par peur.

Task 11: Verify NIC errors, drops, and link state

cr0x@server:~$ ip -s link show dev bond0
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed  mcast
    91234567890  81234567  0       124      0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    78123456789  73456789  0       0        0       0

Signification : Des paquets RX dropped après une mise à jour peuvent venir d’un offload, d’un dimensionnement des rings, d’une régression de pilote, ou d’une incohérence MTU provoquant fragmentation/blackholes.

Décision : Si les drops augmentent régulièrement, traitez cela comme un incident réseau. Vérifiez offloads, MTU bout-en-bout, compteurs du switch, et pilote/firmware.

Task 12: Check bridge and VLAN configuration actually matches what you think you deployed

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet manual
        bond-slaves eno1 eno2
        bond-miimon 100
        bond-mode 802.3ad
        mtu 9000

auto vmbr0
iface vmbr0 inet static
        address 10.10.0.11/24
        gateway 10.10.0.1
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        mtu 9000

Signification : Après une mise à jour, parfois un renommage d’interface, un module manquant, ou une config mal appliquée crée un chemin « presque fonctionnel » mais dégradé (par ex. bond dégradé sur un lien, MTU incohérent).

Décision : Si la config ne correspond pas à votre design prévu, corrigez la config d’abord. Ne benchmarkez pas le chaos.

Task 13: Check corosync ring latency (cluster “slow” can be cluster comms)

cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 1
RING ID 0
        id      = 10.10.0.11
        status  = ring 0 active with no faults
RING ID 1
        id      = 10.20.0.11
        status  = ring 1 active with no faults

Signification : Ceci montre l’état des anneaux, pas la performance. Si vous voyez des faults ou des flaps d’anneau, votre « lenteur » peut être due à un churn d’état du cluster.

Décision : Si les anneaux sont instables, arrêtez et corrigez le réseau/synchronisation temporelle. HA, migrations et coordination stockage s’aggraveront.

Task 14: Look for kernel log hints (driver resets, NVMe timeouts, soft lockups)

cr0x@server:~$ journalctl -k -p warning --since "2 hours ago" | tail -20
Dec 26 12:44:10 server kernel: nvme nvme0: I/O 123 QID 6 timeout, reset controller
Dec 26 12:44:11 server kernel: nvme nvme0: controller reset succeeded
Dec 26 12:58:22 server kernel: ixgbe 0000:3b:00.0: Detected Tx Unit Hang

Signification : Timeouts et resets sont des tueurs de performance qui prennent souvent la forme de « lenteurs aléatoires ». Après une mise à jour, le comportement du pilote peut exposer du matériel ou un firmware marginal.

Décision : Si vous voyez des resets/hangs, cessez de blâmer Proxmox et commencez à isoler combos firmware/driver, câblage et santé matérielle.

Task 15: Validate CPU frequency governor and power settings

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Signification : « powersave » peut être acceptable sur certaines plateformes, catastrophique sur d’autres. Après des mises à jour, les valeurs par défaut peuvent changer, ou des microcodes peuvent modifier le comportement de boost.

Décision : Si des charges sensibles à la latence ont régressé et que vous êtes en powersave, testez le passage en performance (avec gestion du changement) et mesurez.

Task 16: Check VM config for disk controller and cache mode regressions

cr0x@server:~$ qm config 104 | egrep 'scsi|virtio|cache|iothread|cpu|balloon'
balloon: 4096
cpu: x86-64-v2-AES
scsi0: rpool/data/vm-104-disk-0,cache=writeback,iothread=1,discard=on,size=200G
scsihw: virtio-scsi-single

Signification : Les modes de cache et les types de contrôleurs comptent. cache=writeback peut être rapide et dangereux sans garanties de stockage ; d’autres modes sont plus sûrs mais plus lents. virtio-scsi-single avec iothread peut aider la parallélisation.

Décision : Si seules certaines VMs ont régressé, comparez leurs configurations. Un modèle CPU changé ou un iothread manquant peut expliquer qu’une charge donnée semble « tout est plus lent ».

Régressions de stockage : ZFS, Ceph et « où sont passés mes IOPS ? »

La plupart des incidents « Proxmox est lent » après mise à jour sont en fait des incidents de latence de stockage. L’hyperviseur reçoit les reproches parce que c’est la couche commune. Le stockage est l’endroit où les petits changements deviennent une douleur visible.

ZFS sur Proxmox : les schémas classiques de régression

ZFS est fantastique quand on respecte ses besoins : RAM, disposition saine des vdevs, et une politique claire pour les écritures sync. Il est aussi impitoyable quand on l’utilise comme ext4 avec des vibes.

1) Les écritures sync sont devenues coûteuses

Les bases de données et les disques de VM font des écritures sync. Si votre stockage sous-jacent ne peut pas les engager vite, tout s’arrête. Déclencheurs courants après une mise à jour :

• Un périphérique utilisé comme SLOG est maintenant lent, défaillant ou manquant.
• Une mise à jour du noyau a modifié le comportement NVMe ou la mise en file.
• La charge a légèrement changé et a franchi un seuil où les pics de latence deviennent constants.

Vérifiez si vous avez un SLOG et s’il est sain :

cr0x@server:~$ zpool status
  pool: rpool
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            nvme0n1 ONLINE       0     0     0
            nvme1n1 ONLINE       0     0     0
        logs
          nvme2n1   ONLINE       0     0     0

Décision : Si un dispositif de log dédié existe, vérifiez qu’il n’est pas le goulot. Un SLOG lent peut transformer les écritures sync en mélasse.

2) Vdev spécial et points chauds métadonnées

Si vous utilisez des special vdevs (métadonnées/petits blocs), une régression sur ce périphérique nuit à tout. Vérifiez la latence inégale avec iostat et la santé SMART des périphériques.

3) Le comportement de l’ARC a changé à cause d’une pression mémoire

Après des mises à jour, vous pouvez exécuter plus de services (modules mgr Ceph, exporters, daemons supplémentaires), ou la comptabilité des conteneurs a changé. L’ARC se retrouve compressé, la latence de lecture augmente, et vous obtenez un « lent aléatoire » qui est en fait une « tempête de cache miss ».

4) Inadéquation recordsize vs charge

Le recordsize n’est pas un jouet de tuning ; c’est une décision de disposition des données. La plupart des images VM vont bien avec 128K, mais certaines charges I/O aléatoires bénéficient de blocs plus petits. Les mises à jour ne changent pas recordsize, mais elles modifient l’environnement au point que la mauvaise adéquation devient visible.

Ceph sur Proxmox : santé d’abord, tuning ensuite

Ceph n’est pas « un disque ». C’est un système distribué qui stocke des octets. Après une mise à jour, les tueurs de performance les plus courants sont :

• OSDs qui flapent à cause de problèmes réseau ou timeouts
• Recovery/backfill consommant I/O et réseau
• MTU ou offloads NIC incompatibles provoquant perte de paquets et retransmissions
• Changements CRUSH ou reweight déclenchant rebalancing
• Changements côté client noyau (si vous utilisez RBD) affectant la latence

Si vous êtes lent et que Ceph n’est pas HEALTH_OK, considérez l’avertissement comme cause racine jusqu’à preuve du contraire.

Benchmarquez avec précaution, ou vous diagnostiquerez votre propre erreur

Utilisez fio uniquement quand vous comprenez le blast radius. Ne lancez pas un benchmark d’écriture aléatoire sur un pool de production à midi et appelez cela « diagnostics ». Vous vous diagnostiquerez dans un incident.

Cela dit, un benchmark contrôlé et limité peut confirmer si la performance de stockage hôte a fondamentalement changé :

cr0x@server:~$ fio --name=latcheck --filename=/rpool/data/latcheck.bin --size=2G --direct=1 --rw=randread --bs=4k --iodepth=16 --numjobs=1 --runtime=20 --time_based=1 --group_reporting
latcheck: (groupid=0, jobs=1): err= 0: pid=18821: Thu Dec 26 14:10:12 2025
  read: IOPS=52.1k, BW=203MiB/s (213MB/s)(4062MiB/20001msec)
    slat (nsec): min=920, max=112k, avg=2450.1, stdev=2100.4
    clat (usec): min=60, max=7800, avg=286.2, stdev=120.4
    lat  (usec): min=63, max=7805, avg=289.0, stdev=121.0

Signification : Vous cherchez la distribution de latence : moyenne et maximum. Quelques ms max sont généralement acceptables ; des dizaines/centaines de ms max sous faible charge indiquent des blocages stockage.

Décision : Si ceci est drastiquement pire que votre baseline connue (ou pire que d’autres hôtes), concentrez-vous sur la santé des périphériques, les logs noyau, le travail d’arrière-plan ZFS/Ceph, et la configuration de stockage.

CPU et ordonnancement : temps volé, affinité et surprises du noyau

Quand le stockage est correct, l’ordonnancement CPU est la prochaine régression commune après une mise à jour. Proxmox est Linux ; Linux est excellent ; Linux est aussi parfaitement capable de vous ordonnancer dans un fossé si vous lui donnez les mauvaises contraintes.

Régression CPU commune après mise à jour : scaling de fréquence

Certaines mises à jour changent le pilote CPUfreq utilisé (intel_pstate vs acpi-cpufreq), ou réinitialisent un governor tune. Le symptôme est prévisible : la performance mono-thread chute, la latence augmente, et l’utilisation CPU globale peut sembler encore modeste.

Vérifiez la politique actuelle :

cr0x@server:~$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 2>/dev/null | head
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:powersave
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:powersave

Décision : Si vous attendez une performance consistante, envisagez de définir explicitement une politique (et documentez-la). Mesurez avant et après ; ne la basculez pas et n’annoncez pas la victoire sans mesures.

Tempêtes d’IRQ et burn softirq

Après des mises à jour de pilotes NIC, vous pouvez voir un comportement d’interruptions différent. Symptômes :

• Fort %soft dans mpstat
• Baisse du débit réseau pendant que le CPU augmente
• Augmentation des paquets drop

Regardez les interruptions :

cr0x@server:~$ cat /proc/interrupts | head -15
           CPU0       CPU1       CPU2       CPU3
  0:         42          0          0          0   IO-APIC   2-edge      timer
 24:   81234567   79234561   80123455   81111222   PCI-MSI  524288-edge  ixgbe
 25:       1024       1100       1008       990    PCI-MSI  524289-edge  ixgbe

Décision : Si un ou deux CPUs sont martelés par des interruptions après la mise à jour, étudiez l’affinité IRQ et la configuration des queues NIC. Ne « corrigez » pas cela en donnant simplement plus de vCPU aux VMs.

Pinning CPU : excellent quand c’est correct, brutal quand c’est faux

Le pinning peut améliorer la performance pour des charges sensibles à la latence. Il peut aussi créer de la contention artificielle quand vous changez la topologie CPU, le microcode, ou le comportement d’ordonnancement du noyau.

Vérifiez les VMs épinglées et leurs masques CPU. Dans Proxmox, cela se trouve souvent dans la config VM (cores, cpulimit, cpuunits) et dans les outils de tuning au niveau hôte.

Les mises à jour du noyau peuvent aussi changer la façon dont CFS répartit les tâches sur les CPUs. Si vous êtes trop serré en pinning et que vous avez de lourdes interruptions d’I/O de complétion sur les mêmes cœurs, vous vous battez contre vous-même.

Régressions réseau : bridges, offloads, MTU et corosync

Les régressions réseau après mise à jour sont sournoises. Les tests de débit peuvent sembler corrects, mais le trafic sensible à la latence (réplication stockage, corosync, petits RPC) en souffre.

MTU incohérent : le classique « ça marche mais c’est lent »

Si vous utilisez des jumbo frames (MTU 9000) sur bonds/bridges, assurez-vous que c’est cohérent bout-en-bout : NIC, bond, bridge, ports switch, VLANs, et points pairs (réseaux de stockage inclus). Une incohérence peut mener à de la fragmentation ou des pertes selon le chemin et le comportement du bit DF.

Vérifiez le MTU à chaque couche :

cr0x@server:~$ ip link show vmbr0 | grep mtu
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Décision : Si certains nœuds affichent MTU 9000 et d’autres 1500, corrigez l’incohérence avant de blâmer le stockage.

Offloads et changements de pilote

Après une mise à jour, les valeurs par défaut d’offloads NIC peuvent changer. Parfois les offloads aident, parfois ils introduisent des bizarreries avec bridges/VLANs ou certains firmwares de switch. Si vous voyez des drops et des retransmissions, vérifiez les paramètres d’offload et testez des changements prudemment.

cr0x@server:~$ ethtool -k eno1 | egrep 'tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Décision : Si vous suspectez un problème lié aux offloads, testez en basculant un réglage à la fois et mesurez. N’éteignez pas tout par mimétisme.

Sensibilité de corosync

Corosync n’a pas besoin d’une grosse bande passante. Il a besoin d’un faible jitter et de peu de pertes. Une petite régression réseau peut provoquer l’instabilité du cluster, qui engendre des dommages secondaires de performance : migrations échouent, décisions HA churnent, opérations de stockage sont retardées.

Recherchez les plaintes corosync :

cr0x@server:~$ journalctl -u corosync --since "24 hours ago" | tail -20
Dec 26 09:15:22 server corosync[1482]: [TOTEM ] Token has not been received in 2500 ms
Dec 26 09:15:22 server corosync[1482]: [TOTEM ] A processor failed, forming new configuration.

Décision : Si vous voyez des timeouts de token, traitez cela comme un problème réseau/temps. Corrigez cela avant de tenter d’autres optimisations de performance.

Modifications QEMU/VM qui nuisent discrètement

Parfois l’hôte est correct et la régression est spécifique : seules les VMs Windows, seule une VM base de données, seules les VMs sur un stockage donné, seules les VMs créées après la mise à jour.

Pilotes virtio et outils invités

Les invités Windows sans pilotes virtio à jour peuvent régresser après des changements côté hyperviseur. Les invités Linux gèrent généralement mieux, mais de vieux noyaux peuvent quand même souffrir des nouvelles fonctionnalités virtio.

Vérifiez si l’agent invité QEMU flappe ou se comporte mal :

cr0x@server:~$ qm agent 104 ping
{"return":{}}

Signification : L’agent répond rapidement. Si cela timeoute sur plusieurs VMs après la mise à jour, vous pourriez avoir un problème hôte plus large ou une incompatibilité QEMU/agent.

Décision : Si les appels agent bloquent, vérifiez les logs QEMU et la charge hôte. Ne supposez pas que c’est « juste l’agent » — cela peut être le symptôme de blocages plus importants.

Modes de cache disque et barrières

Les réglages de cache sont là où les gens vont « accélérer ». Ça peut fonctionner. Ça peut aussi se retourner spectaculairement quand un hôte plante et que votre « rapide » devient « corrompu ».

Après une mise à jour, validez que votre mode de cache et la pile stockage correspondent toujours à la durabilité souhaitée :

• Si vous comptez sur le cache writeback, vous avez besoin d’une protection fiable contre les pertes de puissance et d’une compréhension claire du risque.
• Si vous utilisez ZFS, ne le combattez pas avec des réglages absurdes qui créent un double caching et un comportement d’écriture imprévisible.

Changements de modèle CPU

Un changement de modèle CPU peut causer une régression de performance dans l’invité (extensions crypto, instructions vectorielles, timing). Les mises à jour Proxmox peuvent modifier les valeurs par défaut ou révéler de vieux choix.

Comparez les paramètres de modèle CPU entre une VM « rapide » et une VM « lente » (qm config). Si l’une utilise un modèle très générique, elle peut manquer des extensions dont votre charge bénéficie.

Blague #2 : La manière la plus rapide d’améliorer la performance d’une VM est d’arrêter d’appeler tout « le réseau ». Ce n’est pas le réseau — jusqu’à ce que ça le soit.

Trois mini-récits du monde d’entreprise (anonymisés, plausibles et douloureux)

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

Ils ont mis à jour un cluster Proxmox trois nœuds un vendredi soir calme. Le ticket de changement était propre : mise à jour du noyau, point release Proxmox mineur, reboot de chaque nœud. Dimanche après-midi l’astreinte a reçu une page : le système ERP « gèle au hasard » pendant 5–20 secondes plusieurs fois par heure.

La première hypothèse était classique : « ZFS est lent parce que l’ARC a été réinitialisé par le reboot, il va se rechauffer. » Ils ont attendu. Les blocages ont continué, et maintenant les sauvegardes échouaient aussi. Quelqu’un a commencé à bidouiller les tunables ZFS en production, parce que rien ne dit « dimanche » comme écrire dans /etc/modprobe.d sous pression.

Finalement quelqu’un a regardé journalctl -k et a vu des resets périodiques de contrôleur NVMe. Après la mise à jour, le pilote NVMe se comportait légèrement différemment avec cette révision firmware spécifique. Avant la mise à jour, le périphérique était marginal mais « assez stable ». Après, il ne l’était plus. Le résultat n’était pas une défaillance nette — juste des blocages intermittents qui correspondaient parfaitement aux plaintes des utilisateurs.

La correction fut ennuyeuse : mettre à jour le firmware NVMe vers une version connue bonne et déplacer le stockage des VMs hors du périphérique affecté jusqu’à la fenêtre de maintenance. La performance est revenue immédiatement, et les « réglages » ZFS ont été annulés avec des excuses aux humains futurs.

Leçon : la mauvaise hypothèse n’était pas « ZFS va se rechauffer ». C’était « les mises à jour ne changent que le logiciel ». Elles changent aussi la façon dont le logiciel parle au matériel, et le matériel écoute toujours.

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

Une autre équipe luttait contre les écritures lentes de bases de données sur des VMs. Quelqu’un a lu que mettre un disque VM en cache=writeback améliore la performance. Ça l’a fait. Les graphiques étaient splendides. La latence a chuté, le débit a monté, et tout le monde s’est senti ingénieur stockage pour une journée.

Puis ils ont mis à jour Proxmox. Après la mise à jour, l’hôte a commencé à faire plus d’I/O d’arrière-plan pendant les scrubs, et le writeback le cachait jusqu’à ce qu’il ne le cache plus. Pendant les pics, des sauts de latence sont devenus fréquents. Ils ont « optimisé » davantage en augmentant iodepth VM et en ajoutant plus de vCPU. Maintenant la VM pouvait générer des rafales d’écriture plus vite que le stockage ne pouvait les absorber durablement. Les pics de latence ont empiré. La base de données a commencé à déclencher ses propres timeouts.

Ils ont blâmé la mise à jour. La mise à jour était complice, pas maître. Le vrai problème était que le choix de cache avait changé les modes d’échec et masquait le vrai comportement du stockage sous pression d’écritures sync. Le gain de performance était réel mais pas stable selon les conditions opérationnelles.

La correction finale fut d’aligner durabilité et attentes de performance : déplacer la VM base de données sur un niveau de stockage avec une vraie performance d’écriture sync, s’assurer que le SLOG n’était pas goulot, et utiliser des modes de cache plus sûrs. Ils ont quand même obtenu une bonne performance — juste sans la roulette russe.

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

Un magasin d’entreprise utilisait Proxmox avec Ceph et avait un rituel : avant toute mise à jour, ils enregistraient trois baselines sur chaque nœud — latence I/O hôte (iostat -x), santé et état recovery Ceph (ceph -s), et un petit profil fio sur un volume de test dédié. Ils avaient aussi un plan de mise à jour en rolling avec une pause après chaque nœud pour observer.

Pendant un cycle de mise à jour, juste après le reboot du nœud deux, le profil fio de latence a doublé. Pas catastrophique, mais clairement différent. Parce qu’ils avaient une baseline de la semaine précédente, ce n’était pas « peut-être que c’était toujours comme ça ». C’était nouveau.

Ils ont arrêté la mise à jour. Pas d’héroïsme. Ils ont comparé les logs noyau et ont trouvé un message pilote NIC corrélé à des drops accrus sur le réseau de stockage. Le nœud était monté avec un réglage d’offload différent. Ceph était sain, mais la latence client a augmenté parce que des paquets étaient retransmis sous charge.

La correction fut simple : normaliser les paramètres NIC entre nœuds, vérifier les compteurs du switch, relancer les tests baselines, puis continuer. Les utilisateurs n’ont rien remarqué. Le seul drame eut lieu en revue de changement, où quelqu’un a demandé pourquoi ils « avaient fait une pause pour une si petite différence ». La réponse était simple : les petites différences deviennent de gros incidents à 2 h du matin.

Erreurs courantes : symptômes → cause racine → correctif

Cette section est volontairement spécifique. « Vérifier les logs » n’est pas une solution.

1) Symptom: high load average, but CPU usage looks low

• Cause racine : tâches bloquées sur I/O (iowait élevé), souvent pics de latence stockage après mise à jour.
• Correctif : confirmez avec mpstat et iostat -x ; identifiez quel périphérique/pool est lent ; vérifiez scrub/resilver ZFS ou recovery Ceph ; vérifiez les logs noyau pour timeouts.

2) Symptom: only Windows VMs got slower, especially disk I/O

• Cause racine : incompatibilité pilote virtio ou changement de modèle de contrôleur ; l’invité n’a pas les bons pilotes.
• Correctif : vérifiez le contrôleur VM (qm config) et mettez à jour les pilotes virtio dans l’invité ; évitez de changer les contrôleurs spontanément durant les mises à jour.

3) Symptom: random 5–30 second freezes across multiple VMs

• Cause racine : timeouts/resets de NVMe, problèmes de liaison SATA, ou régression firmware/driver révélée par le nouveau noyau.
• Correctif : vérifiez journalctl -k pour resets/timeouts ; mettez à jour le firmware ; testez un noyau alternatif si disponible ; migrez les VMs chaudes hors du périphérique.

4) Symptom: Ceph-backed VMs slow “sometimes,” worse after upgrade

• Cause racine : Ceph en HEALTH_WARN, recovery/backfill concurrençant l’I/O client ; ou pertes réseau sur le réseau de stockage.
• Correctif : ramenez Ceph à HEALTH_OK ; vérifiez l’état des OSD ; contrôlez les drops NIC ; validez MTU et offloads ; puis tunez les recovery rates.

5) Symptom: migrations slower, HA actions delayed, cluster feels unstable

• Cause racine : timeouts corosync dus au jitter réseau, incohérence MTU, ou problèmes de synchronisation horaire.
• Correctif : confirmez les logs corosync ; vérifiez les anneaux ; inspectez les compteurs NIC ; validez le service de temps ; gardez corosync sur un réseau propre et banal.

6) Symptom: throughput is okay, but tail latency is awful

• Cause racine : mise en file et comportement par rafales ; souvent changement d’ordonnanceur I/O, amplification d’écriture, ou travail d’arrière-plan (scrub/resilver, trim, sauvegardes).
• Correctif : regardez iostat -x await et avgqu-sz ; examinez les tâches d’arrière-plan ; ajustez les plannings ; vérifiez les profondeurs de file ; envisagez des iothreads pour disques VM très occupés.

7) Symptom: network drops increased after upgrade, but link is up

• Cause racine : changement de pilote/offload NIC, sizing des ring buffers, ou problèmes de bonding/LACP.
• Correctif : inspectez ip -s link ; vérifiez les offloads avec ethtool ; contrôlez l’état du bond ; comparez avec d’autres nœuds ; standardisez les paramètres et firmwares.

Listes de contrôle / plan pas-à-pas

Checklist A: 20-minute triage (production-safe)

1. Confirmez les versions : pveversion -v. Notez le noyau et les versions qemu.
2. Vérifiez la charge et l’iowait : uptime, mpstat -P ALL 1 5.
3. Vérifiez la latence des périphériques : iostat -x 1 5. Identifiez le pire périphérique.
4. Vérifiez les warnings noyau : journalctl -k -p warning --since "2 hours ago".
5. Si ZFS : zpool status -v pour scrub/resilver ; zfs get pour paramètres étranges de dataset.
6. Si Ceph : ceph -s ; ne tunez pas la performance tant que c’est dégradé.
7. Vérifiez les drops réseau : ip -s link, confirmez MTU et état du bond.
8. Choisissez une VM lente et comparez son qm config à une VM connue bonne.

Checklist B: 2-hour isolation (find the subsystem)

1. Déterminez si la régression est globale à l’hôte : comparez les métriques entre nœuds ; trouvez le « nœud mauvais ».
2. Si un nœud est pire, comparez logs matériels et versions firmware NIC/stockage (ne présumez pas d’uniformité).
3. Exécutez un petit test fio en lecture seule sur un chemin sûr pour comparer la latence entre nœuds.
4. Inspectez interruptions et charge softirq si le réseau est suspect (/proc/interrupts, mpstat).
5. Vérifiez les jobs d’arrière-plan : scrub/resilver ZFS ; recovery Ceph ; sauvegardes ; trim/discard.
6. Si lié au noyau, envisagez de tester le démarrage sur le noyau précédent (avec plan de rollback) pour confirmer la causalité.

Checklist C: Hardening after you fix it (so next upgrade doesn’t bite)

1. Enregistrez des baselines (distributions de latence, pas seulement des moyennes) : iostat, petit profil fio, métriques de latence VM.
2. Standardisez offloads/MTU NIC entre nœuds ; documentez dans votre processus de build.
3. Planifiez scrubs/resilvers/sauvegardes en dehors des fenêtres d’activité.
4. Gérez le cycle de vie du firmware : NVMe, NIC, BIOS, HBA.
5. Maintenez un nœud canari pour les mises à jour ; mettez-le à jour en premier et observez 24–48 heures si possible.
6. Notez le profil matériel VM connu bon (type de contrôleur, mode cache, modèle CPU) et appliquez-le de façon cohérente.

FAQ

1) « Tout est plus lent après la mise à jour. » Est-ce généralement Proxmox lui‑même ?

Généralement c’est la couche noyau/stockage/réseau qui a changé sous Proxmox. Proxmox est le point d’intégration, donc il reçoit le blâme. Commencez par iowait, latence disque et drops NIC.

2) Comment dire rapidement si c’est le stockage ou le CPU ?

mpstat est votre ami. Un %iowait élevé pointe vers le stockage. Un %usr/%sys élevé avec un iowait faible pointe vers une saturation CPU ou du travail noyau. Confirmez ensuite avec iostat -x.

3) Un scrub/resilver ZFS peut‑il réellement ralentir autant les VMs ?

Oui, surtout sur des pools HDD ou des vdevs déjà sollicités. Il concurrence les I/O et peut augmenter la latence. L’effet dépend de la charge ; les bases de données le ressentent immédiatement.

4) Ceph est en HEALTH_WARN mais « marche en majeure partie ». Dois-je quand même le considérer comme cause ?

Oui. « Marche en majeure partie » est la façon dont les systèmes distribués vous attirent vers la complaisance. Recovery/backfill et PGs dégradés peuvent absolument causer une latence visible par les utilisateurs.

5) Après la mise à jour, la performance disque VM a chuté. Dois‑je changer le mode cache en writeback ?

Pas en premier lieu. Cela peut améliorer la vitesse mais change les propriétés de durabilité. Corrigez d’abord la latence sous-jacente (santé du périphérique, layout du pool, santé Ceph). Si vous changez le mode cache, faites‑le en connaissance de cause et avec acceptation du risque.

6) Pourquoi je vois une load average élevée alors que les CPUs sont inactifs ?

La load inclut les tâches en sommeil ininterruptible (souvent I/O). Vous pouvez donc avoir une load élevée et des CPUs inactifs si le système attend le stockage.

7) Une incohérence MTU peut‑elle vraiment apparaître comme « stockage lent » ?

Absolument. Si votre réseau de stockage perd de gros paquets ou fragmente de façon imprévisible, vous verrez des retransmissions et du jitter. Les protocoles de stockage sont sensibles à cela.

8) Dois‑je rollbacker le noyau immédiatement ?

Si vous avez une forte preuve que la régression est liée au noyau/driver (nouveaux resets/timeouts, messages de hang NIC, avant/après clair), rollbacker est une mitigation valide. Confirmez avec des logs et un test contrôlé. Ne rollbackez pas aveuglément sans comprendre le risque et les implications de sécurité.

9) Est‑il normal que la performance change après un reboot parce que les caches sont froids ?

Un certain changement est normal — ARC et page cache se réchauffent. Mais une lenteur persistante des heures plus tard, ou des blocages périodiques, n’est pas un « cache froid ». C’est un vrai goulot.

10) Comment éviter ça la prochaine fois ?

Mesurez des baselines avant les mises à jour, utilisez un nœud canari, gardez les firmwares cohérents, et arrêtez de considérer le stockage et le réseau comme « configurés et oubliés ». Ils s’en souviennent.

Conclusion : prochaines étapes qui fonctionnent vraiment

Si Proxmox est plus lent après une mise à jour, ne commencez pas par bidouiller les knobs VM. Commencez par prouver quel sous‑système fait tout attendre.

1. Classez le goulot : CPU vs stockage vs réseau. Utilisez mpstat et iostat, pas l’intuition.
2. Vérifiez le travail d’arrière‑plan et les problèmes de santé : resilvers/scrubs ZFS, recovery Ceph, instabilité corosync.
3. Lisez les warnings noyau : timeouts et resets de driver sont des incidents de performance déguisés.
4. Comparez configurations et baselines : trouvez ce qui a changé, mesurez-le, et décidez sur la base des preuves.
5. Une fois stable, durcissez : enregistrez des baselines, standardisez firmware et paramètres NIC/stockage, et exécutez une voie de mise à jour canari.

Suivez ces étapes et vous trouverez généralement la cause avant que la prochaine réunion de statut ne s’invite d’elle‑même à votre calendrier.