Repères · Tous niveaux · Relecture documentaire : 2 octobre 2026. Les exemples sont génériques ; adapter les noms, versions et chemins avant toute modification.
Mesurer activité normale, pointe, sauvegarde et maintenance. Relever mémoire de l’hôte, mémoire des invités, charge CPU, attente disque, débits et temps de réponse applicatifs. Une machine inactive au moment de la visite ne permet pas de conclure qu’elle possède trop de ressources.
Commencer avec un nombre raisonnable de vCPU et l’augmenter si une charge réelle l’utilise. Attribuer davantage de vCPU à toutes les machines peut accentuer la concurrence. Pour un service de jeu, la performance d’un cœur et la latence comptent souvent autant que la somme des cœurs disponibles.
Définir une mémoire suffisante pour le service et sa pointe, tout en conservant une réserve pour l’hôte. Le swap peut amortir certains besoins mais ne remplace pas de la RAM pour une charge soutenue. Une activité swap élevée et une latence qui augmente doivent conduire à rechercher la pression mémoire.
La mémoire dynamique et le ballooning nécessitent le support approprié de l’invité ; valider leur comportement avec le logiciel concerné. Les limites CPU et les priorités doivent refléter les services essentiels. Ne pas sacrifier DNS, pare-feu ou sauvegardes pour une tâche secondaire.
Éviter de superposer mises à jour, vérifications lourdes, sauvegardes et pics d’utilisation. Limiter la concurrence des tâches de fond. Prévoir une politique explicite pour les services secondaires : arrêt seulement si leur état et l’absence d’utilisateurs sont établis, notification et possibilité de reprise.
Un démarrage ordonné peut aider les applications dépendantes du DNS, d’une base ou du stockage. Tester aussi le redémarrage complet de l’hôte pour vérifier que les dépendances se rétablissent vraiment.
Validation : comparer les mêmes indicateurs avant/après et conserver la configuration précédente. Si une augmentation de mémoire ne change rien, rechercher requêtes lentes, stockage, réseau ou erreur applicative avant d’ajouter encore des ressources.
Pour les services exposés, l’optimisation ne doit pas supprimer l’isolation ou contourner les mises à jour de sécurité. Un service plus rapide mais accessible sans contrôle n’est pas une amélioration opérationnelle.
| Mesure | Interprétation | Mauvaise réaction à éviter |
|---|---|---|
| CPU élevé soutenu | Charge réelle ou boucle | Ajouter des vCPU sans examiner le processus |
| Load élevé, CPU modéré | Attente possible, notamment I/O | Conclure automatiquement à un manque de cœurs |
| I/O delay / latence | Stockage ou chaîne d’accès à examiner | Déplacer vers un pool presque plein |
| RAM disponible faible | Besoin applicatif, cache ou fuite | Réduire aveuglément le cache système |
| Swap active sous charge | Pression mémoire possible | Croire que le swap équivaut à de la RAM |
| OOM dans l’invité | Limite atteinte ou application non bornée | Redémarrages automatiques infinis |
Pour une petite VM, commencer avec peu de sockets virtuels et un nombre de cœurs justifié. Le type CPU host expose les capacités du processeur courant et peut limiter la migration vers un autre modèle ; un modèle commun facilite certaines migrations, au prix de fonctions disponibles. Les NUMA virtuels se conçoivent en lien avec la topologie et la charge, pas comme une case « performance » universelle.
Une limite CPU plafonne, un poids relatif arbitre la contention. Donner 16 vCPU à chaque petite VM n’offre pas 16 cœurs physiques dédiés et peut compliquer l’ordonnancement. Une application monothread dépend surtout d’un cœur disponible et rapide.
Pour une VM, distinguer mémoire maximale et minimum de ballooning ; l’OS et ses pilotes doivent le prendre en charge. Une base sensible peut nécessiter une allocation plus prévisible. Pour un CT, la limite mémoire et la configuration de swap interagissent avec les limites du noyau hôte ; tester dans l’invité. Toujours réserver de la RAM à Proxmox, au cache de stockage et aux opérations de sauvegarde.
Le ZFS ARC est un cache utile, pas une preuve de fuite. Le plafonner peut se justifier avec une mesure de contention, mais le choix dépend du volume de données et des invités. Ne pas copier un pourcentage arbitraire d’un serveur très différent.
Les limites IOPS/débit peuvent protéger les autres invités contre une charge de sauvegarde ou un atelier. Définir une limite mesurée et vérifier son effet sur le service. IO thread, VirtIO et discard ont des prérequis ; plus de cases cochées n’équivaut pas à plus de vitesse. Le lien Ethernet, le NAS ou la base distante peuvent être le vrai goulot.
Une application utilise régulièrement presque toute sa mémoire et subit des OOM. Vérifier d’abord fuite et cache applicatif, puis augmenter par palier si l’hôte dispose d’une réserve. Observer un cycle réel, relire les logs, mesurer le temps de réponse et la mémoire. Conserver la valeur précédente pour revenir en arrière si le changement dégrade les autres services.
Pour un serveur secondaire facultatif, l’arrêt automatique sous forte charge doit exiger qu’il soit vide, vérifier plusieurs mesures successives et utiliser un arrêt propre. Ne pas tuer une session active sur un simple pic. La reprise doit avoir un délai et des seuils distincts pour éviter des allumages/extinctions en boucle.
Documenter avant/après, période de mesure et résultat métier. Le bon dimensionnement est celui qui atteint un objectif de service avec une réserve, pas celui qui remplit tous les graphiques.