Optimisation des performances Proxmox : guide pratique de mise en œuvre

Introduction

L'optimisation des performances de Proxmox VE échoue souvent parce que les opérateurs copient des conseils génériques sans connaître leur version, leur matériel ou le goulot d'étranglement de leur charge de travail. Ce guide vous propose une méthode pratique, étape par étape, pour diagnostiquer et corriger les problèmes de performances courants dans Proxmox, depuis la contention CPU jusqu'à la latence réseau en passant par la lenteur du stockage. Chaque étape comprend une commande concrète, la sortie attendue et un moyen de vérifier l'amélioration. Vous apprendrez également à revenir en arrière en toute sécurité si les changements ne donnent pas les résultats escomptés.

Nous nous concentrons sur les scénarios rencontrés par les développeurs, les consultants DevOps et les équipes techniques de startups : machines virtuelles (VM) qui laguent, conteneurs en manque de CPU, sauvegardes qui saturent les liens réseau et stockage devenu goulot d'étranglement. À la fin de ce guide, vous serez capable d'observer un problème, d'effectuer un changement ciblé, de mesurer le résultat et de documenter la reprise si nécessaire.

Toutes les commandes supposent un hôte Proxmox VE 7.x ou 8.x avec un accès root ou sudo. Remplacez les espaces réservés comme <VMID> par vos valeurs réelles. Testez toujours dans un environnement hors production d'abord.

Inventaire de version et d'environnement

Avant de modifier quoi que ce soit, connaissez votre version de Proxmox et la configuration de l'hôte. Exécutez :

pveversion

Sortie typique :

pve-manager/8.1.4/9f9d7a1c (running kernel: 6.5.11-7-pve)

Cela vous indique la version majeure et le noyau, ce qui est important car certains paramètres de réglage dépendent de la version du noyau ou de QEMU.

Ensuite, vérifiez le CPU, la mémoire et la disposition du stockage :

lscpu | grep -E 'Model name|CPU\(s\)|Thread|Core|Socket'
free -h
df -hT

Exemple de sortie sur un serveur à deux sockets :

Model name:            Intel(R) Xeon(R) Silver 4314 CPU @ 2.40GHz
CPU(s):                64
Thread(s) per core:    2
Core(s) per socket:    16
Socket(s):             2

Cela montre que la topologie NUMA est importante pour le placement des VM.

Pour le stockage, listez vos datastores :

pvesm status

Une sortie saine :

Name             Type     Status           Total            Used       Available        %
local             dir     active        98497780        16036680        77410820   16.28%
local-lvm     lvmthin     active       500000000       120000000       380000000   24.00%

Si vous voyez un statut autre que actif, enquêtez avant de continuer.

Point clé : Enregistrez votre état de référence. Sauvegardez la sortie de ces commandes dans un fichier pour comparaison ultérieure.

Chemin de configuration sûr

L'optimisation des performances de Proxmox est plus sûre lorsque vous modifiez une chose à la fois et testez. Utilisez l'interface graphique ou la CLI, mais comprenez ce que fait chaque réglage. Nous couvrirons le CPU, la mémoire, le stockage et le réseau dans des sous-sections distinctes.

Optimisation du CPU

Identifier la contention CPU : Vérifiez l'utilisation du CPU de l'hôte par VM :

qm list

Puis, pour une VM :

qm monitor <VMID> --commands info cpus

Mais une méthode plus simple consiste à utiliser top dans la VM et à comparer avec la charge de l'hôte. Pour des métriques plus précises au niveau de l'hôte, activez le serveur de métriques Proxmox (InfluxDB ou Prometheus) ou utilisez perf.

Ajuster les unités CPU et l'affinité : Si une VM est affamée en raison d'un trop grand nombre de vCPU sur un hôte occupé, réduisez les vCPU ou définissez une affinité CPU. Par exemple, épinglez la VM 100 aux cœurs hôtes 0-3 :

qm set 100 --cpu cputype=host --cores 4 --cpuunits 2048
qm set 100 --affinity 0-3

cpuunits vaut par défaut 1024 ; une valeur plus élevée donne plus de temps CPU en cas de contention. Mais évitez de trop épingler si vous n'avez pas assez de cœurs.

Vérifier : Exécutez un benchmark CPU dans la VM avant et après :

sysbench cpu --cpu-max-prime=20000 run

Comparez le temps total. S'il s'améliore, c'est bon ; sinon, revenez en arrière.

Optimisation de la mémoire

Ballooning et limites : Utilisez le ballooning mémoire pour récupérer la RAM inutilisée, mais soyez prudent avec les VM sensibles à la latence. Activez le ballooning :

qm set <VMID> --balloon 4096

Cela fixe le balloon minimum à 4096 Mo (la VM démarrera avec plus). Mieux : définissez un minimum et un maximum raisonnables :

qm set <VMID> --memory 8192 --balloon 4096

Vérifier : Vérifiez l'utilisation réelle de la mémoire dans la VM et free -h sur l'hôte.

Huge pages pour les grosses VM : Si vous exécutez des bases de données ou des charges de travail en mémoire, les huge pages réduisent les ratés TLB. Sur l'hôte, allouez par exemple 2 Go de huge pages :

Modifiez /etc/default/grub et ajoutez default_hugepagesz=1G hugepagesz=1G hugepages=16 à GRUB_CMDLINE_LINUX, puis mettez à jour grub et redémarrez. Ou utilisez sysctl pour des pages de 2 Mo :

sysctl vm.nr_hugepages=512

Ensuite, configurez la VM pour utiliser les huge pages :

qm set <VMID> --hugepages 2

Vérifier : Vérifiez /proc/meminfo | grep Huge avant et après le démarrage de la VM.

Optimisation du stockage

Choisir le bon type de stockage :

• Pour les bases de données et les IOPS élevées : utilisez des SSD NVMe avec LVM-thin ou ZFS.
• Pour le stockage en vrac : des disques durs avec Ceph ou RAID ZFS.

Vérifier les performances du stockage : Utilisez fio sur l'hôte pour benchmarker un datastore :

fio --name=test --filename=/var/lib/vz/images/test.img --size=1G --rw=randwrite --bs=4k --ioengine=libaio --direct=1 --numjobs=1 --runtime=30 --time_based --group_reporting

Notez les IOPS et la latence. Un bon SSD SATA devrait donner plus de 10k IOPS en écriture aléatoire ; NVMe plus de 50k.

Activer le cache write-back pour les VM sur RAID avec batterie : Si votre stockage dispose d'une batterie ou d'un supercondensateur, activez le write-back pour de meilleures performances :

qm set <VMID> --scsi1 local-lvm:32,cache=writeback

Vérifier : Exécutez fio dans la VM et comparez.

Optimisation du réseau

Activer le multiqueue pour un débit élevé : Si une VM a besoin de plus de 1 Gbit/s ou de nombreuses connexions, activez le multiqueue. D'abord, définissez le type de machine de la VM sur q35 et activez le multiqueue :

qm set <VMID> --machine q35 --net0 virtio,bridge=vmbr0,multiqueue=4

Ensuite, dans la VM, assurez-vous que le pilote virtio-net supporte le multiqueue et définissez le nombre de files d'attente égal aux vCPU.

Vérifier : Utilisez iperf3 entre deux VM ou hôte et VM.

Régler le bridge et sysctl : Sur l'hôte, augmentez les tampons réseau :

sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728
sysctl -w net.ipv4.tcp_rmem='4096 87380 134217728'
sysctl -w net.ipv4.tcp_wmem='4096 65536 134217728'

Persistez dans /etc/sysctl.d/99-proxmox-performance.conf.

Bonnes pratiques générales

• Snapshot avant les changements : Pour les VM, prenez un snapshot avec qm snapshot <VMID> before_tuning.
• Utilisez l'environnement de test : Ne réglez jamais la production en direct sans tests préalables.
• Un changement à la fois : Si quelque chose casse, vous connaissez la cause.
• Documentez tout : Tenez un journal avec horodatages, changements et résultats de vérification.

Vérification et diagnostics

Après avoir effectué un changement, vous devez vérifier que les performances se sont réellement améliorées et n'ont pas causé de régressions. Utilisez à la fois les métriques de l'hôte et de l'invité.

Métriques au niveau de l'hôte

# Charge CPU et principaux processus
top

# Attente E/S et utilisation des périphériques
iostat -x 1 5

# Utilisation de la mémoire
free -h

# Débit réseau
iftop -i vmbr0

Métriques au niveau de l'invité

Dans la VM, exécutez des outils similaires : top, iostat, free et ping pour vérifier la latence.

Outils de benchmark

• CPU : sysbench cpu run
• Mémoire : sysbench memory run
• Stockage : fio avec différents motifs (lecture aléatoire, écriture aléatoire, séquentiel)
• Réseau : iperf3 entre deux points finaux.

Exemple : Vérifier l'optimisation du CPU

Supposons que vous ayez défini des unités CPU et une affinité pour la VM 100. Exécutez sysbench cpu --cpu-max-prime=20000 run dans la VM avant et après. Notez le temps total.

Avant :

CPU speed:
    events per second:  1200.0

General statistics:
    total time:                          10.0000s

Après :

CPU speed:
    events per second:  1500.0

General statistics:
    total time:                          8.0000s

Une amélioration de 25 % indique un succès.

Outils de surveillance

Les graphiques intégrés de Proxmox montrent le CPU, la mémoire, le réseau et les E/S disque. Pour des données historiques, configurez InfluxDB ou Prometheus avec Grafana. Cela aide à repérer les tendances et les anomalies.

Modes de défaillance et récupération

Même avec une planification minutieuse, les changements peuvent dégrader les performances ou casser des choses. Voici les échecs courants et comment les récupérer.

Cas 1 : La VM devient insensible après un changement d'affinité CPU

Échec : La VM démarre mais est extrêmement lente ; la console montre un vol CPU élevé.

Cause probable : L'affinité est épinglée à des cœurs hôtes occupés ou partagés avec d'autres VM épinglées.

Récupération : Supprimez l'affinité :

qm set <VMID> --delete affinity

Redémarrez ensuite la VM. Sinon, revenez à un snapshot.

Cas 2 : Les performances du stockage chutent après l'activation du cache write-back

Échec : La latence FSYNC augmente, les applications signalent une corruption des données après une panne de courant.

Cause probable : Le cache write-back est dangereux sans RAID avec batterie.

Récupération : Désactivez le cache write-back :

qm set <VMID> --scsi1 local-lvm:32,cache=none

Ou passez à writethrough ou directsync.

Cas 3 : Le débit réseau reste inférieur aux attentes après l'activation du multiqueue

Échec : iperf3 ne montre qu'environ 1 Gbit/s malgré une NIC 10G et le multiqueue.

Cause probable : Le multiqueue n'est pas activé dans l'invité, ou le nombre de vCPU ne correspond pas.

Récupération : Dans la VM, vérifiez ethtool -l eth0 et définissez les files d'attente combinées pour correspondre. Si cela ne fonctionne toujours pas, désactivez le multiqueue :

qm set <VMID> --net0 virtio,bridge=vmbr0

Redémarrez la VM.

Cas 4 : L'hôte devient insensible après des changements sysctl

Échec : Les paramètres du noyau provoquent une instabilité (rare).

Récupération : Redémarrez sur un noyau précédent depuis GRUB, puis annulez les paramètres sysctl dans /etc/sysctl.d/ et exécutez sysctl -p.

Principes généraux de récupération

• Ayez toujours une sauvegarde ou un snapshot avant de faire des changements.
• Connaissez la commande pour inverser un changement (par exemple, qm set avec la valeur opposée).
• Si un changement cause des problèmes, revenez immédiatement en arrière et réévaluez.
• Tenez un journal des changements avec horodatages pour corréler les problèmes.

Liste de contrôle opérationnelle

Utilisez cette liste avant et après toute tâche d'optimisation des performances sur Proxmox.

Avant l'optimisation

• [ ] Enregistrez la version de Proxmox (pveversion) et le noyau.
• [ ] Notez le matériel de l'hôte : modèle du CPU, cœurs, nœuds NUMA, RAM, type de stockage.
• [ ] Identifiez le symptôme spécifique (par exemple, VM lente, vol CPU élevé, faibles IOPS de stockage).
• [ ] Prenez des snapshots de toutes les VM affectées.
• [ ] Créez une base de référence des performances à l'aide de benchmarks (sysbench, fio, iperf3).
• [ ] Vérifiez la configuration actuelle avec qm config <VMID> ou pct config <CTID>.
• [ ] Vérifiez les réglages existants (par exemple, paramètres sysctl, affinité CPU) qui pourraient entrer en conflit.
• [ ] Planifiez un changement à la fois.
• [ ] Documentez l'état actuel et l'amélioration attendue dans un journal.

Pendant l'optimisation

• [ ] Effectuez le changement à l'aide de la CLI ou de l'interface graphique Proxmox.
• [ ] Enregistrez la commande exacte et l'horodatage.
• [ ] Redémarrez les services ou la VM concernés si nécessaire.
• [ ] Ne faites pas de changements supplémentaires tant que la vérification n'est pas terminée.

Après l'optimisation

• [ ] Exécutez les mêmes benchmarks qu'avant et comparez les résultats.
• [ ] Vérifiez les journaux de l'hôte et de l'invité pour les erreurs (journalctl -xe, dmesg).
• [ ] Surveillez pendant au moins 24 heures sous charge normale.
• [ ] Si les performances sont pires, revenez immédiatement en arrière en utilisant la commande d'inversion documentée.
• [ ] Si les performances sont meilleures, mettez à jour la documentation et envisagez d'appliquer aux autres nœuds de manière contrôlée.
• [ ] Mettez à jour le manuel opérationnel avec le nouveau paramètre et son effet.

Exemple d'entrée de liste de contrôle

Conclusion

L'optimisation des performances de Proxmox est un processus systématique : connaissez votre environnement, faites un changement à la fois, vérifiez avec des métriques réelles et ayez un plan de récupération. Ce guide fournit des commandes pratiques pour l'optimisation du CPU, de la mémoire, du stockage et du réseau, ainsi que des exemples de sorties attendues et de modes de défaillance.

Commencez par des changements à faible risque, benchmarkez religieusement et documentez tout. La pire erreur est d'appliquer plusieurs changements sans test et de perdre la trace de ce qui a causé un problème. Utilisez des snapshots, des sauvegardes et un journal pour garder le contrôle.

À mesure que votre charge de travail augmente, revisitez ces points d'optimisation. La flexibilité de Proxmox signifie qu'il y a toujours place à l'optimisation, mais seulement avec une observation et une validation minutieuses.

Maintenant, choisissez une VM avec un problème de performances connu, suivez la liste de contrôle et optimisez en toute sécurité. Vos utilisateurs vous remercieront.