De combien de RAM un serveur a-t-il besoin ? Prévoir capacité, ECC et marge

Comprendre d’abord le goulet d’étranglement

La RAM contient les données et l’état des programmes auxquels les processeurs doivent accéder rapidement. Lorsque la mémoire utilisable manque, le système peut transférer des pages sur disque, réduire ses caches ou arrêter des processus. Un logiciel de gestion peut alors ralentir même si le processeur paraît peu occupé. À l’inverse, 64 GB supplémentaires n’accéléreront pas une application qui attend une interface externe ou un unique cœur de processeur saturé.

Une consommation élevée ne suffit pas à justifier un achat : les systèmes d’exploitation utilisent utilement la RAM libre comme cache. Il faut examiner la mémoire disponible, la pression récurrente, les échanges avec le disque et le temps de réponse de l’application, mesurés simultanément. Linux propose Pressure Stall Information pour mesurer le temps d’attente des tâches lorsque le processeur, la mémoire ou les entrées-sorties manquent. Cela aide à distinguer un véritable blocage d’un cache utile. Noyau Linux : Pressure Stall Information ↗

Relevez au moins un cycle d’activité représentatif : journées normales, sauvegardes, rapports et traitements de fin de mois. Un mardi matin calme ne représente pas une importation nocturne. Notez également le nombre d’utilisateurs, le volume de données et la version logicielle. Vous pourrez ainsi expliquer l’évolution des besoins après une mise à niveau.

Exemple : la RAM d’un petit hôte de virtualisation

Le plan suivant est un exemple hypothétique pour une entreprise exploitant plusieurs services internes. Les valeurs représentent des budgets mémoire supposés nécessaires simultanément, et non les exigences minimales de produits précis. On part de 64 GB physiques pour vérifier s’ils laissent assez de place au fonctionnement quotidien, à la maintenance et à la croissance.

Avec une marge de planification choisie de 25 %, on obtient 50 × 1,25 = 62,5 GB. Une configuration de 64 GB pourrait être une première étape, mais elle reste proche de cette limite. Les 14 GB disponibles représentent 28 % du besoin initial. Si le seul budget de la base augmente de 12 GB, la réserve est presque épuisée. Une extension ou le déplacement d’une charge devient alors nécessaire.

Prévoir un budget propre aux bases de données

La taille d’une base sur SSD ne détermine pas directement son besoin en RAM. Une grande base peut fonctionner avec un petit jeu de données fréquemment utilisé. Une plus petite peut soudain demander beaucoup de mémoire pour des tris simultanés. Il faut donc examiner ensemble données actives, index, requêtes concurrentes et maintenance régulière.

Pour un serveur dédié disposant d’au moins 1 GB de RAM, PostgreSQL propose environ 25 % comme valeur de départ pour shared_buffers. C’est un point de départ de configuration, pas une recommandation pour dimensionner tout le serveur sur ce seul ratio. work_mem peut être alloué par opération de tri ou de hachage ; plusieurs opérations et sessions peuvent multiplier le besoin total. Les autres services et le cache du système exigent aussi de la place. PostgreSQL : paramètres mémoire et consommation des ressources ↗

Vérifiez d’abord les requêtes, les index et la concurrence inutile. Un export exécuté en même temps qu’un import et une sauvegarde peut provoquer des pics bien moins élevés si ces tâches sont décalées. Ajouter de la RAM est pertinent lorsque les mesures montrent un jeu de données actives croissant. Pour une application défectueuse dont la consommation augmente sans limite, cela peut seulement retarder la panne.

L’ECC est une propriété du système complet

La mémoire ECC peut détecter et corriger certaines erreurs mémoire. Les erreurs couvertes et la réaction du système dépendent de la plateforme. Intel précise que l’ECC nécessite le support du processeur et du chipset. Avant commande, les validations de la carte mère, du micrologiciel et des modules précis doivent également correspondre. Intel : conditions de prise en charge de l’ECC ↗

La DDR5 avec ECC interne à la puce ne transforme pas automatiquement un serveur en système protégé de bout en bout par ECC. Cette correction interne couvre les erreurs dans la puce DRAM. Une protection supplémentaire au niveau système nécessite des modules ECC adaptés et une plateforme compatible. Les ECC UDIMM et RDIMM ne sont pas non plus librement interchangeables. Achetez selon la liste de compatibilité du système, pas seulement selon la capacité et la fréquence. Kingston : DDR5 et ECC interne à la puce ↗

Planifier ensemble modules, canaux mémoire et extension

Une même capacité totale peut offrir des bandes passantes différentes selon la répartition des modules. Les canaux mémoire du processeur et les recommandations de peuplement du fabricant comptent. Garder beaucoup d’emplacements libres peut sembler intéressant pour plus tard, mais une configuration très déséquilibrée aujourd’hui gaspille de la bande passante. Des modules supplémentaires peuvent aussi imposer une autre fréquence autorisée. Suivez le manuel de la plateforme choisie.

• Vérifier la capacité maximale et les tailles de modules prises en charge par le processeur et la carte mère.
• Consigner le type de DIMM, le nombre de modules par canal et les mélanges autorisés.
• Prévoir le peuplement initial et une deuxième étape d’extension précise, avec nomenclature.
• Vérifier les modules validés et leur disponibilité avant de choisir une configuration initiale serrée.
• Après installation, contrôler la capacité reconnue, le fonctionnement de l’ECC et les messages matériels.

Séparer surallocation et réserve en cas de panne

On peut attribuer nominalement aux machines virtuelles plus de mémoire que la capacité physique. La viabilité dépend de leur activité simultanée réelle, de l’hyperviseur et des mécanismes de récupération mémoire. Pour des bases sensibles à la latence, le calcul ne doit pas dépendre du faible besoin occasionnel d’un autre invité. Un hôte à l’aise en fonctionnement normal peut subir une pression lorsque plusieurs invités redémarrent.

Avec deux hôtes et une reprise automatique, le total de GB est également trompeur. Si les VM essentielles ont besoin de 80 GB, elles doivent tenir dans la capacité restante après la perte d’un hôte, en incluant les besoins de cet hôte. Deux machines de 64 GB ne remplissent pas cet objectif simplement parce que 128 GB sont disponibles au quotidien. Arrêter volontairement les systèmes de test moins importants peut être une solution documentée.

Quand le plan devient fiable

Définissez les critères avant l’achat : par exemple, un rapport mensuel dans un délai convenu, aucune interruption de processus liée à la mémoire et une marge suffisante pendant les sauvegardes simultanées. Testez ensuite ce processus précis avec des données réalistes adaptées au test. Répétez les mesures après des changements importants du logiciel ou des données.

Le résultat devrait tenir sur une page : hypothèses de charge, pics mesurés, budget mémoire, besoins en cas de panne et limite d’extension. Une deuxième personne peut alors comprendre la décision. Au prochain devis, il devient possible de distinguer un système plus cher qui résout un problème précis d’une simple vente de capacité supplémentaire sans valeur opérationnelle.