Si vous administrez un nœud Proxmox VE depuis un moment, vous avez déjà vu le scénario. Tout va bien, puis un jour une VM ou un conteneur se met à ramer. L’interface répond encore mais avec une lourdeur bizarre. Et là, en regardant le nœud, vous voyez le mot qui fait peur : swap.
Le problème, ce n’est pas « avoir un peu de swap ». Le problème, c’est quand le swap devient un mode de vie. Sur un hyperviseur, ça peut vite devenir destructeur, parce que vous transformez une ressource très rapide (la RAM) en une ressource très lente (le disque), et tout le monde souffre, surtout vos VM les plus importantes.
Dans ce lab, je vous montre comment optimiser l’usage RAM sur Proxmox, comment détecter les signes avant la catastrophe, et comment éviter le swap « destructeur » sans tomber dans l’excès inverse (tuer l’OOM killer et faire exploser des services au hasard). On va faire ça proprement, comme au Tech Lab.
Si vous aimez ce genre de retours terrain, il y en a d’autres sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/) : des labs Proxmox, réseau, supervision, et des choses qui sentent un peu la salle serveur.
Comprendre pourquoi le swap devient « destructeur » sur un nœud Proxmox
Sur un poste Linux classique, un peu de swap peut lisser les pics. Sur un nœud Proxmox, c’est souvent l’inverse. Pourquoi.
- Les VM ont déjà leur propre gestion mémoire interne.
- Quand l’hôte commence à swapper, il le fait pour maintenir ses processus et ceux de QEMU, mais au final ce sont les VM qui ralentissent.
- Et si le swap est sur SSD, vous ajoutez en bonus de l’usure et de la latence. Sur HDD, c’est encore pire.
Le côté « destructeur », ce n’est pas juste les performances. C’est aussi l’effet boule de neige : latence disque, tâches Proxmox qui traînent, IOwait qui monte, migrations qui se figent, sauvegardes qui dérapent, et parfois un nœud qui devient presque impossible à administrer à distance.
Les symptômes typiques à repérer (avant qu’il soit trop tard)
Avant de toucher à des réglages, il faut apprendre à lire les signes. En pratique, je regarde toujours ces points.
- Swap utilisé qui monte et ne redescend pas.
- Load average élevé alors que le CPU n’est pas à 100 %.
- IOwait élevé (top, htop, ou grafana si vous supervisez).
- Des VM « ok » côté CPU, mais qui ont des latences monstrueuses.
- Proxmox GUI qui charge lentement, ou les actions qui restent en « running ».
Commandes utiles sur le nœud :
bash free -h swapon --show vmstat 1 top cat /proc/meminfo | egrep 'MemAvailable|SwapTotal|SwapFree|Dirty|Writeback'
Et côté Proxmox, l’onglet Summary du nœud est déjà un bon indicateur. Si vous voyez la barre swap active, ce n’est pas « un détail ».
Avant d’optimiser : vérifier la vraie cause du manque de RAM
On a tendance à accuser Proxmox. Souvent, la cause est plus banale.
1) Sur-allocation trop agressive des VM
Vous avez mis 8 Go partout « au cas où », puis vous avez multiplié les VM. Le total provisionné dépasse la RAM physique. Et au moindre pic, l’hôte souffre.
Petit rappel terrain : si vous avez 64 Go de RAM, et 10 VM à 8 Go, ça fait 80 Go provisionnés. Tant que tout le monde ne consomme pas à fond, ça passe. Mais le jour où ça passe pas, ça passe vraiment pas.
2) ZFS qui « mange » la RAM
ZFS utilise l’ARC (cache) et c’est souvent une bonne chose. Mais sur un petit serveur, ou sur un nœud trop chargé, l’ARC peut pousser le système à swapper si rien n’est cadré.
3) Un service hôte qui fuit (ou qui grossit)
Ça arrive plus qu’on ne croit : un agent de backup, un export NFS, un collecteur, ou même un process lié à une stack de supervision.
Pour repérer vite les plus gros consommateurs :
bash ps aux --sort=-%mem | head smem -tk | head # si smem est installé
Réglage numéro 1 : swappiness (et pourquoi ce n’est pas magique)
Le paramètre vm.swappiness décide à quel point le noyau préfère swapper. Sur un hyperviseur, on veut généralement swapper le moins possible.
Vérifier :
bash sysctl vm.swappiness cat /proc/sys/vm/swappiness
Recommandation courante sur Proxmox : 10 (parfois 1 sur des serveurs très sensibles, mais 10 reste raisonnable).
Appliquer temporairement :
bash sysctl -w vm.swappiness=10
Rendre persistant :
bash echo "vm.swappiness=10" > /etc/sysctl.d/99-proxmox-ram.conf sysctl --system
Important : ça ne supprime pas le swap, ça le rend juste moins probable. Si votre nœud manque réellement de RAM, il swappe quand même.
Réglage numéro 2 : zfs_arc_max (si vous utilisez ZFS)
Si votre stockage local est en ZFS (très fréquent avec Proxmox), vous devez au moins connaître ce point.
Voir la taille actuelle de l’ARC :
bash arc_summary | head
cat /proc/spl/kstat/zfs/arcstats | head
Limiter l’ARC avec zfs_arc_max. Exemple, sur un nœud 64 Go, vous pouvez limiter à 16 Go ou 24 Go selon votre charge. Ici, exemple à 16 Go :
- Ajouter dans
/etc/modprobe.d/zfs.conf:
bash options zfs zfs_arc_max=17179869184
- Rebuild initramfs et reboot :
bash update-initramfs -u reboot
Ça se discute selon vos workloads, mais l’idée est simple : éviter que l’ARC prenne tout l’espace « confortable » et mette le système sous pression mémoire.
Réglage numéro 3 : ballooning, oui, mais en sachant ce que vous faites
Le ballooning permet à Proxmox de reprendre de la RAM à une VM si elle n’en a pas besoin, pour la donner à d’autres.
Ça sonne parfait, mais.
- Il faut que l’agent (virtio balloon) soit supporté et installé correctement dans la VM.
- Certaines charges n’aiment pas qu’on leur retire de la RAM en cours de route.
- Et si vous mettez des minima trop bas, vous créez une VM « malade » qui swap à l’intérieur, ce qui n’est pas mieux.
Dans l’interface Proxmox, sur la VM :
- Memory : mémoire max
- Minimum memory : mémoire minimale (balloon)
Une approche raisonnable : fixer un minimum réaliste (pas ridicule), et garder du slack sur l’hôte. Le but est de lisser, pas de tricher sur la physique.
Réglage numéro 4 : corriger la surcharge, la vraie (dimensionnement et règles simples)
Je vais être direct. Si vous êtes constamment à 90 % de RAM, vous êtes déjà en zone rouge.
Quelques règles simples qui évitent pas mal de drames :
- Garder au moins 10 % à 20 % de RAM libre ou disponible (MemAvailable) sur l’hôte, en régime normal.
- Éviter de provisionner « large » sur les VM sans justification.
- Standardiser vos tailles : des profils (2 Go, 4 Go, 8 Go) et vous ajustez après observation.
- Mettre en place un monitoring avec alerting sur MemAvailable et swap.
Sur le blog BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), c’est typiquement le genre de point qu’on transforme en mini-projet : supervision, seuils, alertes, puis analyse d’incident.
Éviter le swap destructeur : faut-il désactiver le swap
On voit souvent : « Désactivez le swap. » Ça peut marcher. Et ça peut aussi vous exploser à la figure.
Option A : garder du swap mais le rendre inoffensif (souvent le meilleur compromis)
- Swappiness bas (10)
- Swap sur un support correct
- Dimension swap raisonnable
- Et surtout, ne pas être en sous-dimensionnement RAM chronique
Vous gardez un filet de sécurité. Le noyau peut respirer si un process fait un pic temporaire.
Option B : swap quasi nul
Mettre 512 Mo ou 1 Go de swap, juste pour éviter certains cas limites. Là encore, c’est un filet, pas une solution.
Option C : swap off (à faire uniquement si vous maîtrisez l’OOM)
Vous pouvez désactiver :
bash swapoff -a
Et commenter la ligne swap dans /etc/fstab.
Mais. En cas de pression mémoire, Linux va tuer des processus (OOM killer). Sur un nœud Proxmox, ça peut tuer un process QEMU, ou autre, et vous perdez une VM net.
Donc si vous faites ça, faites-le en connaissance de cause, et idéalement avec supervision et marges RAM.
Activer zram : une alternative très utile sur certains nœuds
zram crée un swap compressé en RAM. Dit comme ça, ça semble absurde, mais en pratique ça peut absorber des pages peu actives en les compressant. Ça évite de taper le disque, donc ça évite une partie du swap destructeur.
Sur Debian (base de Proxmox), vous pouvez utiliser systemd-zram-generator ou des scripts. Le choix dépend de votre politique. Pour un lab, je conseille de tester d’abord sur un nœud non critique.
Vérifier après mise en place :
bash swapon --show zramctl
zram ne remplace pas la RAM physique. Mais ça peut sauver un nœud de la noyade quand le swap disque commence à gratter.
Cas concret : nœud Proxmox qui swap après ajout de 2 VM
Un cas typique.
- Nœud 32 Go RAM, stockage ZFS.
- 6 VM existantes, tout allait bien.
- Ajout de 2 VM, chacune 6 Go « parce que Windows Server, on sait jamais ».
- Résultat : swap qui monte, latence disque, sauvegarde PBS qui prend 3 fois plus de temps.
Correctifs appliqués :
- Swappiness à 10.
- Limite ARC à 8 Go (sur 32 Go, ça change tout).
- Réduction RAM des VM trop généreuses : 6 Go vers 4 Go après observation réelle.
- Ballooning activé sur 2 VM « peu critiques » avec minimum réaliste.
- Alerte Zabbix sur MemAvailable < 3 Go et swap > 256 Mo.
Le swap n’a pas disparu totalement. Mais il est redevenu un filet. Plus un mode de fonctionnement.
Check-list rapide : quoi faire quand vous voyez du swap sur Proxmox
- Mesurer :
free -h,swapon --show,vmstat 1- vérifier MemAvailable, IOwait
- Identifier :
ps aux --sort=-%mem | head- ZFS ARC, services hôtes
- Corriger :
- vm.swappiness=10
- limiter zfs_arc_max si ZFS
- ajuster RAM des VM, activer ballooning proprement
- prévoir marge RAM, pas juste « au plus juste »
- Prévenir :
- monitoring + alertes
- revoir vos profils de VM
- documenter vos seuils, vos règles
Images utiles à insérer dans votre doc interne (ou vos supports de cours)
Si vous rédigez un support pour les étudiants, ou pour votre équipe, ces captures sont très parlantes :
- Dashboard Proxmox (nœud) avec RAM et swap.
free -havant et après réglage.- Graphe de MemAvailable et swap sur 24 h.
- Comparatif latence disque quand swap actif.
Vous pouvez aussi intégrer des captures dans vos articles sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), ça aide énormément à transformer une panne « floue » en diagnostic concret.
Conclusion : l’objectif, ce n’est pas zéro swap, c’est zéro souffrance
Optimiser la RAM sur Proxmox, ce n’est pas une incantation. C’est un équilibre.
Un nœud stable, c’est souvent :
- assez de RAM,
- un ZFS cadré si vous l’utilisez,
- des VM dimensionnées selon leur usage réel,
- et un swap qui reste un filet, pas une béquille permanente.
Si vous voulez, je peux aussi proposer une variante « lab étudiant » avec objectifs, questions, et étapes notées, à publier sur le blog BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/). On peut en faire un très bon TP : mesurer, ajuster, vérifier, et écrire le petit rapport d’exploitation.
Questions fréquemment posées
Pourquoi le swap devient-il un problème "destructeur" sur un nœud Proxmox ?
Le swap devient destructeur sur un nœud Proxmox car il remplace la RAM rapide par un disque beaucoup plus lent, ce qui ralentit considérablement les VM. De plus, cela crée un effet boule de neige avec une latence disque accrue, des tâches Proxmox ralenties, une montée de l'IOwait, des migrations figées et des sauvegardes problématiques, rendant parfois l'administration distante quasi impossible.
Quels sont les symptômes typiques indiquant que le nœud Proxmox utilise trop de swap ?
Les signes avant-coureurs incluent une utilisation du swap qui monte sans redescendre, un load average élevé malgré un CPU non saturé, une IOwait élevée observée via top ou htop, des VM avec une bonne charge CPU mais des latences élevées, ainsi qu'une interface Proxmox GUI lente ou bloquée sur des actions "running".
Comment vérifier si le manque de RAM est dû à une sur-allocation des VM ?
Il faut comparer la RAM totale provisionnée aux VM avec la RAM physique disponible. Par exemple, si vous avez 64 Go de RAM et que vous avez alloué 8 Go à 10 VM (80 Go au total), cela dépasse la RAM physique et peut provoquer du swap. La gestion attentive de la mémoire allouée aux VM est essentielle pour éviter ce problème.
Quel impact a ZFS sur l'utilisation de la RAM dans Proxmox ?
ZFS utilise l'ARC (Adaptive Replacement Cache) pour améliorer les performances en utilisant la RAM comme cache. Sur un petit serveur ou un nœud très chargé, cette utilisation peut pousser le système à swapper si elle n'est pas correctement configurée ou limitée.
Comment identifier rapidement un service hôte qui consomme excessivement la mémoire ?
Vous pouvez utiliser la commande bash ps aux --sort=-%mem | head pour voir les processus consommant le plus de mémoire. L'outil smem (si installé) permet aussi d'obtenir un classement détaillé. Cela aide à repérer les agents de backup, export NFS ou collecteurs qui pourraient causer des fuites mémoire.
Quelle est la recommandation concernant le paramètre vm.swappiness sur Proxmox et pourquoi ?
Le paramètre vm.swappiness contrôle la propension du noyau à utiliser le swap. Sur un hyperviseur comme Proxmox, il est conseillé de réduire cette valeur pour limiter le swap au minimum et préserver les performances des VM. Une valeur courante recommandée est 10 afin d'éviter un usage excessif du swap sans désactiver complètement cette fonctionnalité importante.
0 Commentaires