Proxmox : 12 erreurs qui tuent les performances

Proxmox VE, sur le papier, c’est simple. Un hyperviseur type 1, KVM, LXC, un stockage à la carte, une interface web plutôt clean. Et pourtant… je vois encore et encore les mêmes installations qui « marchent », oui. Mais qui rament, qui ont des latences bizarres, des backups qui explosent la prod, des VM qui plafonnent à 30 % de ce qu’elles devraient sortir.

Le pire, c’est que ce n’est pas une seule grosse faute. C’est souvent une accumulation de petites erreurs. Des choix par défaut, des tutos copiés, des réglages laissés « plus tard ».

Dans cet article, je te liste 12 erreurs concrètes qui flinguent les performances sur Proxmox. Avec, à chaque fois, quoi regarder et quoi corriger. Et si tu veux d’autres labs orientés BTS SIO SISR, virtualisation et infra, garde un onglet sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/) parce qu’on empile les retours terrain.

1) Installer Proxmox sur un stockage lent « parce que ça suffit »

Classique. Proxmox installé sur un vieux HDD, ou un SSD SATA fatigué, voire une clé USB. Puis on s’étonne que l’interface web accroche, que la base de données de config réponde lentement, que les logs mettent une éternité, que le node a une latence permanente.

Proxmox, ce n’est pas juste « un OS qui boote ». Il écrit. Beaucoup. Journald, cluster filesystem (pmxcfs), tâches cron, métriques, etc.

À faire :

• Installer Proxmox sur SSD correct, idéalement NVMe si le serveur le permet.
• Éviter les supports « non faits pour » (clé USB).
• Sur ZFS, bien dimensionner RAM et disques (on y revient).

Check rapide :

• pveperf pour un indicateur de perf disque.
• iostat -x 1 pour voir si le disque est en saturation.

2) Garder le CPU en mode économie d’énergie

Tu peux avoir un Xeon ou un Ryzen qui tape fort… mais si le gouverneur CPU est en mode powersave, tu te retrouves avec des fréquences qui montent mal, donc des VM qui ont des pics de latence.

Sur certains serveurs, le BIOS est réglé « Power Saving » ou « Balanced ». Sur d’autres, Linux colle un governor qui n’aide pas.

À faire :

• Vérifier côté BIOS : profil performance, C-states trop agressifs, etc.
• Vérifier côté Linux : governor.

Commandes utiles : bash cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor lscpu | grep MHz

Selon la plateforme, tu peux utiliser cpupower : bash apt update && apt install -y linux-cpupower cpupower frequency-set -g performance

3) Sous-dimensionner la RAM, puis activer des trucs « comme si »

Proxmox va faire tourner :

• l’hôte Debian,
• KVM,
• LXC,
• cache disque,
• éventuellement ZFS (ARC),
• éventuellement Ceph.

Et si tu mets 16 Go pour faire tourner 10 VM « petites », ça finit souvent en swap, ou en ballooning trop agressif, ou en OOM killer. Et la perf tombe d’un coup.

À faire :

• Laisser une marge RAM confortable pour l’hôte.
• Sur ZFS, ne pas oublier l’ARC.
• Sur Ceph, ne pas rêver : il faut de la RAM.

Surveillance : bash free -h swapon --show vmstat 1

4) Utiliser ZFS sans comprendre ce que ça coûte

ZFS, c’est génial. Snapshots, intégrité, réplication. Mais ce n’est pas magique. Si tu actives ZFS sur 32 Go de RAM, avec des disques moyens, et des VM I/O intensives, tu peux te retrouver avec des latences élevées.

Erreurs typiques :

• ZFS sur HDD en RAIDZ, mais des VM qui font plein de petites écritures random.
• Pas de SLOG, pas de special vdev, pas d’optimisation. Et on blame Proxmox.

À faire (selon le cas) :

• Préférer mirror plutôt que RAIDZ pour du stockage VM.
• Ajuster recordsize (dataset VM souvent à 16K ou 128K selon charge, mais pas au hasard).
• Surveiller l’ARC et la latence.

Commandes : bash zpool status zfs list arc_summary

5) Laisser le stockage VM sur du thin-provisioning sans monitoring

LVM-thin, c’est pratique. Mais quand le thin pool arrive à saturation, c’est le drame. Et souvent, ça arrive en pleine journée. Résultat : latences, erreurs d’écriture, VM qui figent.

À faire :

• Monitorer le thin pool.
• Garder une marge.
• Mettre des alertes (mail, Zabbix, Prometheus, même un script cron au pire).

Commandes : bash lvs -a pvesm status

6) Choisir le mauvais type de disque virtuel, ou le mauvais bus

VirtIO est ton ami. SATA émulé, IDE, même SCSI sans optimisations, ça peut coûter cher.

Bon réflexe :

• Disque : SCSI avec contrôleur VirtIO SCSI single ou disque VirtIO Block, selon usage.
• Activer IO thread si pertinent (souvent utile sur SCSI).
• Pour Windows : drivers VirtIO installés.

Dans Proxmox, ça se joue dans le hardware de la VM. Et oui, ça change vraiment la perf.

À vérifier :

• Le disque est-il en IDE « par défaut » parce que tu as importé une VM vieille ?
• Le cache disque est-il réglé n’importe comment ?

7) Activer « write back cache » sans batterie, sans UPS, sans conscience

Le cache écriture agressif peut donner un benchmark qui fait plaisir. Et puis un jour, coupure électrique. FS corrompu, DB cassée, VM qui ne boote plus.

Donc oui, performance vs sécurité. Mais il faut décider.

Recommandation simple :

• Si pas d’onduleur et pas de contrôleur RAID avec cache protégé : éviter les réglages dangereux.
• Sur ZFS, on évite de tricher avec les caches au mauvais endroit.

8) Oublier les options CPU correctes, et brider les VM

Combien de VM en « kvm64 » générique, sans AES-NI exposé, sans features, parce que « ça marche ». Sauf que ça bride :

• le chiffrement,
• la compression,
• certains workloads.

À faire :

• Sur un cluster homogène : CPU type « host ».
• Sur un cluster hétérogène : définir un modèle cohérent, mais pas trop bas.

Dans la config VM :

• CPU : host souvent.
• Vérifier le NUMA si grosses VM.

Attention : CPU host rend la migration live entre nœuds différents plus compliquée. Donc il faut réfléchir cluster, pas juste VM.

9) Ignorer le NUMA sur les grosses VM

Si tu donnes 16 vCPU et 64 Go RAM à une VM sur un serveur NUMA (multi-socket ou architecture qui segmente), et que tu ignores complètement la topologie, tu peux te prendre des latences mémoire.

À faire :

• Activer NUMA dans la VM si gros sizing.
• Éviter de sur-allouer des vCPU « pour être tranquille ». Ça peut empirer.

Outils : bash numactl --hardware lscpu | grep NUMA

10) Réseau mal pensé : bridge sur NIC cheap, drivers bof, MTU incohérent

Les perfs réseau, ça se casse vite :

• NIC Realtek sur serveur « home lab »,
• drivers approximatifs,
• offloading mal géré,
• MTU 9000 activé sur un nœud, pas sur l’autre, pas sur le switch. Bonjour la fragmentation et les soucis intermittents.

À faire :

• Privilégier Intel, Broadcom, Mellanox selon budget.
• Vérifier la cohérence MTU de bout en bout si jumbo frames.
• Séparer management, stockage, VM traffic si possible (VLAN minimum).

Commandes : bash ip -s link ethtool eth0 bridge link

11) Sauvegardes au mauvais moment, sans limitation : la prod se fait écraser

Proxmox Backup (PBS) ou backup classique vzdump, c’est vital. Mais si tu lances toutes les sauvegardes à 02:00, full speed, compression max, sur le même stockage que la prod… tu te tires une balle dans le pied.

Symptômes :

• latence disque qui monte pendant les backups,
• VM qui lag,
• services applicatifs qui time-out.

À faire :

• Échelonner les backups.
• Limiter bande passante ou I/O (selon infra).
• Utiliser PBS correctement (incrémental, chunking).
• Mettre le repo PBS sur du stockage adapté.

Réglages à regarder :

• Compression : utile, mais coûte CPU.
• Mode snapshot : selon FS/guest agent.

Pour plus d'informations pratiques concernant la gestion des sauvegardes et des réseaux dans un environnement Proxmox, je vous recommande de consulter ce document.

12) Faire tourner Ceph « pour tester » sur 3 nœuds sous-dimensionnés

Ceph, c’est top, mais pas « gratuit ». Beaucoup installent Ceph parce que c’est dans l’interface Proxmox, et parce que ça fait cluster sérieux. Puis ils le mettent sur :

• des disques mixtes,
• pas assez de RAM,
• pas assez de réseau,
• pas assez de CPU,
• sans séparation de trafic.

Résultat : tout le cluster devient lent, même les VM qui ne devraient pas.

À faire :

• Si tu veux Ceph : réseau dédié (idéalement 10 GbE minimum), disques homogènes, sizing.
• Sinon : rester simple. ZFS replication, NFS performant, ou PBS + réplication Proxmox selon besoin.

Commande utile : bash ceph -s ceph osd perf

---

Mini checklist rapide (à relire avant de chercher des « tweaks »)

• Stockage hôte sur SSD/NVMe correct.
• BIOS et governor CPU en mode performance.
• RAM suffisante, swap sous contrôle.
• ZFS seulement si tu assumes le coût.
• VM en VirtIO, contrôleur bien choisi.
• CPU type réfléchi (host vs modèle).
• NUMA activé pour grosses VM.
• Réseau cohérent, NIC serveur, MTU aligné.
• Backups étalés et maîtrisés.
• Ceph seulement si infra prête.

Conclusion

Ce qui tue les performances sur Proxmox, ce n’est pas Proxmox. C’est surtout les « petits choix » faits vite, puis oubliés. Un disque système lent. Un governor CPU mal réglé. Un ZFS posé là parce que ça faisait pro. Des backups qui tapent au pire moment. Et d’un coup, tu te retrouves à débugger des lenteurs floues, impossibles à expliquer à ton chef de projet, ou à ton client, ou à ton jury.

Si tu veux, on peut en faire un vrai labo pas à pas, avec mesures avant/après (pveperf, iostat, fio, latences VM, tuning VirtIO, etc.). Sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), l’idée c’est justement ça : des articles qui sentent le terrain, et qui aident à progresser vite, sans folklore.

Si tu me dis ton contexte (CPU, RAM, type de stockage, nombre de VM, ZFS ou LVM, backup PBS ou non), je peux te pointer les 3 erreurs les plus probables chez toi.

Questions fréquemment posées

Quels sont les impacts d'installer Proxmox VE sur un stockage lent ?

Installer Proxmox VE sur un support lent comme un vieux HDD, un SSD SATA usé ou une clé USB entraîne des latences élevées, une interface web peu réactive, des ralentissements dans la base de données de configuration et des logs qui s'écrivent lentement. Proxmox nécessite un stockage rapide car il effectue beaucoup d'écritures (journaux, système de fichiers en cluster, métriques). Il est recommandé d'utiliser un SSD performant, idéalement NVMe, et d'éviter les supports non adaptés.

Comment optimiser la gestion du CPU pour améliorer les performances sous Proxmox VE ?

Il est crucial de vérifier que le gouverneur CPU n'est pas en mode économie d'énergie (powersave), ce qui limite la fréquence du processeur et provoque des latences dans les VM. Au niveau BIOS, privilégiez un profil 'Performance' et évitez des états C trop agressifs. Sous Linux, utilisez la commande 'cpupower frequency-set -g performance' pour forcer le mode performance du CPU.

Pourquoi est-il important de bien dimensionner la RAM sur un serveur Proxmox VE ?

Proxmox fait tourner plusieurs services gourmands : l'hôte Debian, KVM, LXC, le cache disque, ZFS (ARC), Ceph... Une RAM insuffisante provoque du swap, du ballooning excessif ou même l'arrêt brutal de processus (OOM killer), dégradant fortement les performances. Il faut donc laisser une marge confortable pour l'hôte et prendre en compte les besoins spécifiques comme l'ARC de ZFS ou Ceph.

Quelles précautions prendre lorsqu'on utilise ZFS avec Proxmox VE ?

ZFS offre des fonctionnalités puissantes mais exigeantes en ressources. Utiliser ZFS avec peu de RAM (ex : 32 Go) et des disques moyens peut engendrer des latences élevées. Évitez RAIDZ pour des VM avec beaucoup d'écritures aléatoires ; préférez plutôt le miroir. Ajustez le 'recordsize' selon la charge (souvent 16K ou 128K). Surveillez régulièrement l'ARC et la santé du pool avec 'zpool status' et 'arc_summary'.

Quels sont les risques liés à l'utilisation du thin provisioning sans surveillance sur Proxmox VE ?

Le thin provisioning via LVM-thin est pratique mais risqué si le pool arrive à saturation : cela peut provoquer des erreurs d'écriture, une dégradation importante des performances voire une interruption de service pour les VM concernées. Il est essentiel de monitorer régulièrement l'espace disponible sur le thin pool pour éviter ces problèmes.

Quelles sont les erreurs fréquentes qui dégradent les performances sur Proxmox VE ?

Les performances dégradées résultent souvent d'une accumulation de petites erreurs : installation sur stockage lent, CPU en mode économie d'énergie, RAM insuffisante, mauvaise configuration ou méconnaissance de ZFS, utilisation non surveillée du thin provisioning... Ces erreurs cumulées génèrent latences bizarres, backups impactant la production et plafonnement des VM. La vigilance sur chaque aspect est clé pour optimiser Proxmox.