La planification de la capacité des serveurs échoue lorsque les équipes achètent de la mémoire vive en se basant sur les moyennes des feuilles de calcul plutôt que sur les données relatives à la charge de travail, les règles relatives aux plates-formes et la réalité de l'approvisionnement. Voici un guide pratique pour éviter les erreurs coûteuses en matière de mémoire serveur.
Commencez par des preuves.
Trop d'exercices de planification de la capacité de mémoire des serveurs commencent par une cellule budgétaire, un vague pourcentage de “croissance future” et la conviction de quelqu'un que l'utilisation moyenne du dernier trimestre peut prédire le comportement de la charge de travail de l'année prochaine entre les machines virtuelles, les bases de données, les couches de cache, les travaux par lots, les conteneurs et les événements de basculement. Pourquoi prétendons-nous encore que le dimensionnement de la mémoire n'est qu'une question d'arithmétique ?
Je me contenterai de dire que la mauvaise planification de la capacité des serveurs n'est souvent pas due à l'ignorance. Elle est due à la commodité de l'organisation. Les achats veulent un numéro de pièce propre. Les finances veulent un chiffre avant la fin du mois. L'infrastructure veut une marge de manœuvre mais ne veut pas la défendre. Les propriétaires d'applications parlent d“”utilisation normale" parce qu'ils n'ont pas mesuré la taille de l'ensemble résident en période de pointe, la rotation de l'ensemble de travail, le comportement des NUMA ou la pression exercée par le swap en cas d'affluence importante.
Mais les serveurs ne se soucient pas de l'optimisme des salles de réunion.
Ils s'intéressent aux canaux, aux rangs, aux types de modules DIMM, à la symétrie des sockets de l'unité centrale, au comportement ECC, à la prise en charge du BIOS et à ce qui se passe lorsqu'une charge de travail qui utilise habituellement 420 Go nécessite soudainement 690 Go parce qu'un planificateur de requêtes, un travail de sauvegarde, un tas JVM, un ensemble de données Redis ou un lot d'inférence IA a changé du jour au lendemain.
Le ministère américain de l'énergie a indiqué que les centres de données américains consommaient 176 TWh en 2023, contre 58 TWh en 2014, et qu'il prévoyait une consommation de 325 à 580 TWh d'ici 2028 dans son rapport sur les centres de données. rapport sur la demande d'électricité des centres de données. Il ne s'agit pas d'une histoire d'énergie abstraite. C'est une histoire de densité de serveurs. Et la densité des serveurs est une histoire de mémoire.
Lorsque chaque rack, chaque watt, chaque fenêtre de maintenance et chaque bon de commande sont sous pression, l'estimation des besoins en mémoire vive des serveurs devient une taxe. Une taxe discrète. Une taxe récurrente.
Pour les équipes chargées des achats qui ont besoin de véritables voies d'approvisionnement, je commencerais par mettre en correspondance les plates-formes installées avec un système d'information structuré. Catalogue de mémoires DDR4 pour serveurs et, pour les déploiements plus récents, un fichier Chemin d'approvisionnement en mémoire serveur DDR5. C'est en mélangeant ces conversations dès le début que les équipes achètent en toute confiance la mauvaise chose.
Les moyennes mentent.
Si un cluster de virtualisation utilise en moyenne 58% de mémoire, la conclusion paresseuse est qu'il dispose de 42% de capacité de réserve. Ce chiffre peut sembler correct dans un tableau de bord, mais il peut s'effondrer lorsque deux hôtes entrent en maintenance, qu'une base de données bruyante se déverse dans la mémoire, que Kubernetes réorganise les pods ou qu'un travail d'analyse tire un mois de données chaudes dans le cache.
La meilleure question n'est pas “Quelle quantité de mémoire vive avons-nous utilisée en moyenne ?”.”
La meilleure question à se poser est la suivante : “Quelle est la plus grande mémoire de travail dont nous avons besoin tout en respectant les exigences en matière de latence, de basculement, de sauvegarde et de maintenance ?”
Je veux les données horribles. Pression de la mémoire aux heures de pointe. Événements de gonflement. Activité d'échange. Défauts de page. Déséquilibre NUMA. Croissance du pool de mémoire tampon de la base de données. Plafonds du tas de la JVM. Frais généraux de l'hyperviseur. Décroissance du taux de réussite de la mémoire cache. Compression de la mémoire. Impact du basculement de l'hôte. Il s'agit là de la planification de la capacité de la mémoire vive. Le reste est de la décoration.
Un véritable plan de mémoire de serveur doit comprendre
La vérité : si votre modèle de capacité ne peut pas survivre à un hôte défaillant et à un pic de charge de travail mal programmé, il ne s'agit pas d'un modèle de capacité. C'est un modèle d'espoir.
ServeurDimm's guide complet pour l'achat de mémoire de serveur a bien cadré les choses : la mémoire d'un serveur ne se choisit pas uniquement en fonction du nombre de gigaoctets. Elle doit correspondre au modèle de serveur, à la génération de CPU, aux règles des canaux de mémoire, au type de DIMM, au rang, à la vitesse supportée et aux exigences de la charge de travail.
“64GB” n'est pas une spécification.
Il s'agit d'une étiquette de capacité, et les étiquettes de capacité sont à l'origine de certaines des erreurs les plus coûteuses dans la planification de la capacité de l'infrastructure informatique, car elles cachent les détails qui décident en fait si le module démarre, se débloque, se trompe ou est rejeté pendant le POST. Un RDIMM DDR4 ECC de 64 Go 3200 2Rx4 n'est pas la même décision d'achat qu'un LRDIMM DDR4 de 64 Go, et un RDIMM DDR5-5600 de 96 Go n'est pas simplement “un plus gros bâton”.”
Les directives de Dell concernant la mémoire PowerEdge stipulent que les RDIMM et les LRDIMM ne peuvent pas être mélangés et que la configuration de la mémoire entre deux CPU doit être identique en termes de taille et de position dans la mémoire. guide de configuration de la mémoire supportée. C'est le genre de phrase ennuyeuse qui permet de sauver des week-ends.
C'est là que les équipes se trompent :
| Erreur de planification courante | Ce que dit la feuille de calcul | Ce dont le serveur a réellement besoin | Conséquence |
|---|---|---|---|
| Achat par capacité uniquement | “Ajouter 768 Go de RAM” | Type, rang, vitesse et emplacement exacts des modules DIMM | Échec du démarrage, downclocking ou population instable |
| Ignorer la symétrie des sockets de l'unité centrale | “Remplir les cases vides” | Canaux équilibrés entre CPU 1 et CPU 2 | Perte de bande passante et mises en page non prises en charge |
| Mélange de RDIMM et de LRDIMM | “Les deux sont des RAM serveur ECC” | Une classe de mémoire prise en charge par règle de plate-forme | Échec POST ou configuration rejetée |
| Planification à partir de l'utilisation moyenne | “Seul le 60% a été utilisé” | Ensemble de travail de pointe et marge de manœuvre pour le basculement | Tempêtes de swap, pics de latence, contention des machines virtuelles |
| Ignorer la synchronisation de l'alimentation | “Commander quand c'est approuvé” | Confirmer le stock, le lot, la garantie et le numéro de série le plus tôt possible | Rafraîchissement retardé, pièces de rechange, calendrier déréglé |
| Traiter les DDR4 et DDR5 comme des choix budgétaires uniquement | “La DDR4 est moins chère” | Génération de plateformes, largeur de bande, densité, cycle de vie | Fausses économies ou pression de rafraîchissement prématuré |
C'est la raison pour laquelle je n'aime pas les appels d'offres vagues du type “Meilleur prix pour une RAM de serveur de 64 Go”. Elles invitent à des réponses vagues.
Un meilleur appel d'offres est le suivant : “Besoin de 200 unités de 64 Go de DDR4-3200 ECC RDIMM 2Rx4, compatibles avec Dell PowerEdge R750. Indiquez le numéro de série exact, l'état, l'état testé, la garantie, le délai de livraison et les alternatives acceptées”.”
C'est une phrase que les marchés publics peuvent défendre.
Pour les acheteurs qui mettent en place des contrôles reproductibles, le Liste de contrôle pour l'approvisionnement en mémoires de serveurs à l'intention des équipes chargées des achats est un lien interne naturel car il pousse la conversation à s'éloigner de l'achat en fonction du prix et à s'orienter vers la compatibilité, les tests, la garantie et le contrôle des fournisseurs.
L'ancienne hypothèse était simple : si le budget est approuvé, la mémoire vive sera là.
Cette hypothèse a mal vieilli.
Reuters a rapporté que le boom de l'IA a créé une grave pénurie mondiale de mémoire, SK Hynix s'attendant à ce que les conditions de pénurie durent jusqu'à la fin de l'année 2027, dans son rapport d'évaluation de l'IA. couverture de la crise de l'approvisionnement en puces à mémoire. Vous pouvez ne pas être d'accord sur l'ampleur de la pénurie pour votre UGS exacte, mais vous ne pouvez plus prétendre que le calendrier d'approvisionnement est distinct de la planification des capacités.
La planification des capacités se résumait autrefois à une question du type : “De combien de mémoire aurons-nous besoin ? ”De combien de mémoire aurons-nous besoin ?"
Aujourd'hui, il s'agit de cinq questions :
C'est sur cette dernière question que je n'ai aucune patience à l'égard des acheteurs amateurs. Si l'équipe ne dispose d'aucun MPN alternatif approuvé, d'aucune flexibilité de marque entre Samsung, Micron, SK hynix ou Kingston, d'aucune exigence de contrôle des lots et d'aucune politique d'utilisation testée pour les anciens parcs de DDR4, alors la “planification de la capacité des serveurs” n'est qu'une prévision sans aucune force d'exécution.
L'analyse de ServerDimm quelles sont les capacités et les types de mémoire de serveur les plus demandés indique la répartition à laquelle je m'attendais sur le marché : Les RDIMM DDR4 ECC de 32 Go et 64 Go sont toujours importants pour la prise en charge de la base installée, tandis que les RDIMM DDR5 ECC de 64 Go, 96 Go et 128 Go apparaissent dans la virtualisation plus dense, l'analytique et la planification adjacente à l'IA.
Oui, la planification de la capacité de la mémoire vive est technique.
Mais il est aussi commercial. Si vous modélisez des RDIMM DDR5-5600 de 96 Go et que vous découvrez ensuite que le prix a changé, que le délai de livraison s'est allongé ou que le fournisseur a substitué un profil de rang différent sans examen, votre modèle n'a pas échoué dans Excel. Il a échoué dans le monde réel.
L'augmentation de la mémoire vive peut être une mauvaise réponse.
Un serveur de base de données qui manque de capacité de mémoire a besoin de plus de RAM. Un hôte de virtualisation qui perd de la bande passante parce que les canaux sont déséquilibrés peut avoir besoin d'un meilleur plan de population DIMM. Un nœud d'analyse engorgé par la bande passante mémoire peut bénéficier d'un nombre réduit de modules DIMM plus rapides par canal plutôt que de remplir chaque emplacement. Une charge de travail qui génère des erreurs de page parce que le tas est mal configuré peut nécessiter une discipline logicielle avant une discipline matérielle.
C'est là que la planification de la mémoire des serveurs devient inconfortable. Les équipes chargées de l'infrastructure aiment acheter pour éviter les problèmes, car l'achat leur donne l'impression d'être décisif. Mais la capacité ne se limite pas au volume. C'est aussi le placement, la bande passante, la latence, la résilience et la capacité de récupération.
Par exemple :
J'examinerais également attentivement les preuves de garantie et de test. La mémoire des serveurs n'est pas un composant décoratif. Elle se trouve sous les bases de données, les systèmes ERP, les hyperviseurs, les contrôleurs de stockage, les pipelines d'IA, les fermes VDI, les tâches de sauvegarde et les applications orientées client. Si un fournisseur ne peut pas expliquer les tests, la garantie et le traitement RMA, je me fiche de l'attractivité du prix de l'article.
C'est là que le Guide de qualité et de garantie pour la mémoire serveur ECC RDIMM a sa place dans le parcours de l'acheteur. Pas après la commande. Avant l'approbation.
Les meilleurs planificateurs de capacités lisent les rapports d'incidents comme les analystes financiers lisent les appels de fonds.
L'incident survenu en juin 2025 chez Google Cloud a entraîné une augmentation des erreurs 503 dans les produits Google Cloud, Google Workspace et Google Security Operations, avec une fenêtre d'incident de trois heures et un chemin de défaillance de la politique de quotas décrits dans le rapport de Google Cloud. rapport officiel d'incident. Il ne s'agissait pas d'une étude de cas sur l'achat de modules DIMM. Mais c'est une leçon de planification des capacités : les contrôles automatisés, les systèmes de quotas, la propagation des métadonnées et les chemins de reprise régionaux peuvent devenir des multiplicateurs de défaillance s'ils ne sont pas testés dans des scénarios peu glorieux.
Un cas plus ancien concernant Google Cloud mérite également d'être lu. En décembre 2020, Google a signalé une panne mondiale de 50 minutes liée à l'authentification, causée par un problème de gestion automatisée des quotas qui a réduit la capacité d'un système central de gestion des identités dans sa base de données de Fiche d'incident sur l'état du nuage. Encore une fois, il ne s'agit pas d'une “défaillance de la mémoire vive du serveur”. Mais la logique de la capacité a échoué d'une manière que les utilisateurs peuvent ressentir.
Quelle est donc la leçon à tirer de la mémoire des serveurs ?
Ne modélisez pas uniquement le chemin normal.
Modéliser la voie de la laideur :
Uptime Institute's Analyse des interruptions annuelles 2025 est une lecture utile, car elle maintient la conversation sur les pannes ancrée dans les causes, les conséquences et la complexité opérationnelle. C'est là qu'intervient la planification professionnelle des capacités : non pas dans le fantasme que chaque système se comporte normalement, mais dans la discipline qui consiste à se demander ce qui échoue lorsque les hypothèses se heurtent les unes aux autres.
Voici la méthode de travail à laquelle je me fie.
Commencez par dresser l'inventaire de la vérité physique. Enregistrez le modèle du serveur, le nombre de CPU, la génération de CPU, la carte DIMM actuelle, la capacité installée, le type de module, le rang, la vitesse, le niveau du firmware et le rôle de la charge de travail. Ne laissez personne omettre la carte des emplacements. C'est là que les corps sont enterrés.
Deuxièmement, mesurez le comportement de la charge de travail. Utilisez des données télémétriques sur 30 à 90 jours dans la mesure du possible. Capturez les pics de consommation de mémoire, la mémoire engagée, la mémoire active, l'échange, les erreurs de page, le comportement du cache, le gonflement, l'allocation de la mémoire de la base de données, les limites du conteneur et les frais généraux de l'hyperviseur. Une semaine est souvent trop courte. Les moyennes sont trop faibles.
Troisièmement, la défaillance et la maintenance du modèle. Si vous utilisez N+1, prouvez-le. Si vous utilisez N+2, prouvez-le également. Si un hôte entre en maintenance et que vos hôtes restants ne peuvent pas absorber la mémoire de la charge de travail sans ballooning ou swap, vous êtes déjà sous-provisionné.
Quatrièmement, appliquer les règles de la plate-forme. Confirmez si la plateforme prend en charge la DDR4 ou la DDR5, les ECC RDIMM ou LRDIMM, la capacité maximale par socket, les DIMM par canal, le comportement de la vitesse à 1DPC ou 2DPC, et si les capacités mixtes sont prises en charge. C'est ici que les règles de Dell, HPE, Lenovo, Supermicro, Intel Xeon et AMD EPYC comptent plus que les opinions.
Cinquièmement, ajoutez la réalité de l'approvisionnement. Si le plan dépend des RDIMM DDR5 de 128 Go, validez le prix, la disponibilité, la garantie, les marques approuvées, les numéros de série exacts, le délai d'exécution et les solutions de remplacement. S'il dépend d'anciens modules DDR4-2666 ou DDR4-3200, confirmez que les stocks testés sont effectivement disponibles avant la publication du calendrier de maintenance.
Une formule pratique se présente comme suit :
Mémoire requise pour le serveur = Mémoire de la charge de travail maximale + frais généraux de l'hyperviseur/OS + marge de manœuvre pour le basculement + réserve de croissance + réserve opérationnelle
Mais la formule n'est utile que si les entrées sont honnêtes. Je souhaite généralement un tampon de croissance de 20% à 30% pour les charges de travail d'entreprise ordinaires, davantage pour l'analytique, le calcul adjacent à l'IA, les bases de données en mémoire, le VDI, les clusters Kubernetes à forte rotation, ou les environnements où les cycles d'approvisionnement sont lents.
Pas joli. Utile.
La planification de la capacité de mémoire des serveurs consiste à calculer la quantité de RAM ECC dont un parc de serveurs a besoin aujourd'hui et plus tard, en fonction du comportement de la charge de travail, des socles de CPU, des règles de peuplement des DIMM, de la densité de virtualisation, de la marge de manœuvre pour le basculement et du délai d'approvisionnement, et pas seulement du nombre total de gigaoctets imprimé sur un devis.
Dans la pratique, cela signifie qu'il faut associer les données d'ingénierie à la discipline d'achat. Un bon plan couvre la génération DDR4 ou DDR5, la prise en charge des RDIMM ou des LRDIMM, le rang, la vitesse, le nombre d'emplacements, les hypothèses de croissance et le coût d'un mauvais module au cours d'une courte fenêtre de maintenance.
Les besoins en mémoire des serveurs sont calculés en ajoutant la mémoire de la charge de travail maximale, les frais généraux du système d'exploitation, les frais généraux de l'hyperviseur, la marge de manœuvre pour le basculement, la croissance prévue et une réserve opérationnelle, puis en vérifiant le résultat par rapport aux règles de peuplement de la mémoire de la plate-forme, aux types de modules DIMM pris en charge, à la disposition des sockets du processeur, aux limites des canaux et à la disponibilité réelle de l'approvisionnement.
L'erreur consiste à n'utiliser que l'utilisation moyenne. Utilisez des ensembles de travail de pointe, et non des mesures de confort. Si la charge de travail est une base de données, une ferme VDI, un cluster Kubernetes, une plateforme analytique ou un hôte de virtualisation, vérifiez le swap, les défauts de page, le gonflement de la mémoire, la pression du cache et les scénarios de basculement avant d'acheter.
Les erreurs de planification de la mémoire serveur les plus courantes consistent à acheter en fonction de la capacité uniquement, à ignorer les règles RDIMM contre LRDIMM, à utiliser l'utilisation moyenne au lieu de la demande maximale, à ignorer la symétrie des sockets CPU, à oublier la marge de manœuvre pour le basculement, à sous-estimer le délai d'approvisionnement et à traiter les décisions DDR4 et DDR5 comme de simples comparaisons de prix.
Ces erreurs semblent généralement anodines lors de l'établissement du devis. Elles deviennent coûteuses lors de l'installation. Un mauvais plan de mémoire peut entraîner une défaillance du POST, un downclocking inattendu, des charges de travail instables, des fenêtres de maintenance manquées, des achats d'urgence et des déficits de capacité qui étaient visibles des mois plus tôt dans la télémétrie.
La mémoire serveur DDR5 n'est pas toujours meilleure que la DDR4, car le bon choix dépend de la plateforme du serveur, des besoins en bande passante de la charge de travail, de l'objectif de densité, du calendrier de rafraîchissement, du budget, de la base installée existante et de la question de savoir si l'équipe développe des systèmes hérités ou construit une nouvelle infrastructure à partir de zéro.
Pour les nouvelles plateformes, les modules DDR5-4800, DDR5-5600 et DDR5-6400 peuvent convenir à une planification à plus haute densité. Pour les parcs existants, les modules DDR4-2933 ou DDR4-3200 peuvent encore être un choix économiquement correct si la compatibilité, la garantie, l'approvisionnement testé et le risque lié au cycle de vie sont correctement contrôlés.
La distinction entre RDIMM et LRDIMM est importante car ces types de mémoire serveur utilisent des conceptions de mémoire tampon différentes, prennent en charge des chemins de capacité différents et ne peuvent souvent pas être mélangés dans le même serveur, ce qui en fait une règle de plate-forme plutôt qu'une préférence d'achat ou une substitution au niveau de la marque.
C'est l'un des moyens les plus faciles pour obtenir un devis. Un acheteur voit l'ECC, la capacité et la vitesse. Le serveur voit la charge électrique, le rang, le comportement du contrôleur de mémoire et les règles de population. Le serveur gagne à tous les coups.
Avant le prochain achat de mémoire de serveur, préparez un dossier d'approbation d'une page.
Indiquez le modèle de serveur, le nombre de CPU, le plan des emplacements actuels, la capacité cible, le profil de la charge de travail, les pics de mémoire, les exigences de basculement, la génération DDR, le type de DIMM, le rang, la vitesse, les MPN approuvés, les alternatives acceptées, les exigences en matière de garantie et le délai de déploiement. Envoyez ensuite ce paquet à un fournisseur capable de répondre avec le même niveau de détail.
Si vous prévoyez une maintenance DDR4, une extension DDR5, des mises à niveau ECC RDIMM, des constructions LRDIMM à haute densité ou l'achat en gros de RAM pour serveur, commencez par consulter la liste de ServerDimm. page des fournisseurs de RAM pour serveurs en vrac, comparer les Mémoire serveur DDR4 ou Mémoire serveur DDR5 et demander un devis avec les détails exacts de la plate-forme.
Ne demandez pas le “meilleur prix”.”
Demandez des preuves.
ServerDimm fournit des mémoires de serveur de marque, neuves et d'occasion, aux distributeurs, aux acheteurs OEM, aux revendeurs et aux équipes des centres de données. Nous prenons en charge l'approvisionnement en DDR4 et DDR5 avec des stocks testés, des vérifications de compatibilité et un service de devis réactif.
Copyright © 2026 Shenzhen Lux Telecommunication Technology Co.,Ltd. Tous droits réservés
