La plupart des serveurs de base de données n'ont pas besoin de la mémoire la plus rapide en premier. Ils ont besoin de suffisamment de RAM validée et compatible pour conserver l'ensemble de travail réel en mémoire, éviter la pagination et protéger le temps de fonctionnement. Mais il y a des exceptions, et des exceptions coûteuses.
La capacité est la première chose à faire.
J'ai vu des équipes dépenser de l'argent pour des modules DIMM à cadence plus élevée alors que leur serveur de base de données continuait à produire des déversements de données temporaires, des changements de mémoire tampon, des lectures de pages et des statistiques d'attente horribles parce que personne n'avait pris la peine de se poser la seule question qui compte avant d'acheter de la RAM pour un serveur de base de données : l'ensemble de travail actif tient-il réellement dans la mémoire lorsqu'il est sollicité ??
Qu'est-ce qu'une mémoire vive plus rapide est censée sauver ?
Voici ma réponse brutale : la plupart des serveurs de base de données ont besoin de plus de capacité de mémoire utilisable avant d'avoir besoin d'une mémoire plus rapide. Ce n'est pas toujours le cas. Mais suffisamment souvent pour que je considère la “RAM plus rapide” comme la deuxième conversation, et non la première.
Une base de données n'est pas un PC de jeu. Le but n'est pas de gagner une capture d'écran de benchmark. Il s'agit de maintenir les tables, les index, les plans d'exécution, les jointures, les tris et les couches de mémoire tampon/cache aussi éloignés que possible des chemins de stockage lents. Lorsque le serveur commence à faire de la pagination, à déverser des données sur le disque ou à expulser constamment des pages utiles de la mémoire, quelques centaines de MT/s supplémentaires sur l'étiquette DIMM ne sauveront pas la conception.
L'étude de terrain de Google, ancienne mais toujours utile, Erreurs de DRAM dans la nature, a analysé plus de 2,5 ans de données sur les parcs de serveurs de production et a constaté que plus de 8% de modules DIMM étaient affectés par des erreurs chaque année. Il ne s'agit pas d'une jolie note de bas de page de laboratoire. C'est pourquoi je me soucie de l'ECC, de la validation et de la discipline en matière d'approvisionnement avant de me préoccuper des déclarations de vitesse de qualité commerciale.
Et puis il y a le coût des pannes. Uptime Intelligence a rapporté dans son Analyse des interruptions annuelles 2024 que 54% des personnes interrogées ont déclaré que leur dernière panne significative, grave ou sévère avait coûté plus de $100 000, dont 16% plus de $1 million. Dites-moi encore pourquoi la décision relative à la mémoire devrait être traitée comme un accessoire de la foire d'empoigne ?
La phrase “combien de RAM faut-il à un serveur de base de données” semble simple. Ce n'est pas le cas.
Je commence par l'ensemble de travail actif : tables chaudes, index chauds, structures temporaires, surcharge de connexion, dimensionnement de la mémoire tampon/cache, octroi de mémoire pour les requêtes, impact de la réplication ou de la sauvegarde, agents de surveillance, réserve du système d'exploitation et pics de concurrence. Je me penche ensuite sur la plate-forme : génération de CPU, génération DDR supportée, emplacements DIMM, nombre de canaux, support RDIMM ou LRDIMM, densité maximale par emplacement, et si le système d'exploitation et l'édition de la base de données peuvent même utiliser la mémoire que je suis sur le point d'acheter.
C'est là que les acheteurs se montrent négligents.
Le serveur SQL en est un bon exemple. Le serveur Limites de l'édition SQL Server 2022 montrent que l'édition Standard a une limite maximale de 128 Go de mémoire pour le pool de mémoire tampon du moteur de base de données par instance, tandis que l'édition Enterprise peut utiliser le maximum du système d'exploitation. Donc, si vous utilisez SQL Server Standard et que vous pensez qu'un achat de 512 Go de RAM alimentera comme par magie le pool de mémoire tampon d'une instance, j'ai de mauvaises nouvelles à vous annoncer.
MySQL raconte une histoire similaire sous un angle différent. L'étude d'Oracle Documentation sur le pool de tampons InnoDB de MySQL 8.4 Le pool de mémoire tampon met en cache les données des tables et des index dans la mémoire principale et, sur les serveurs dédiés, jusqu'à 80% de mémoire physique lui est souvent attribuée. C'est de la capacité qu'il s'agit. Pas de diffuseurs de chaleur RVB. Il ne s'agit pas de vitesse de vanité.
PostgreSQL ajoute un élément supplémentaire. Son documentation actuelle sur les shared_buffers indique qu'une valeur de départ raisonnable pour un serveur de base de données dédié doté d'au moins 1 Go de RAM est de 25% de mémoire système, tout en précisant que PostgreSQL s'appuie également sur le cache du système d'exploitation et que des valeurs supérieures à 40% sont peu susceptibles d'améliorer les performances pour de nombreuses charges de travail. En clair : plus de mémoire sur le serveur de base de données est utile, mais une allocation irréfléchie peut encore nuire.
La vitesse n'a d'importance que plus tard.
Un serveur qui dispose déjà de suffisamment de mémoire vive pour éviter la pagination, réduire les lectures physiques, conserver l'ensemble des index utiles et contrôler les opérations de tri et de hachage peut bénéficier d'une mémoire plus rapide, en particulier lorsque les cœurs de l'unité centrale attendent la bande passante de la mémoire plutôt que l'espace de stockage. Mais il s'agit là d'un diagnostic différent de celui qui consiste à dire que “la base de données semble lente”.”
Posez de meilleures questions.
La charge de travail est-elle OLTP avec des lectures aléatoires et des objectifs de latence serrés ? S'agit-il d'analyse avec des tables de faits étendues ? S'agit-il de SQL Server avec un stockage en colonnes ? S'agit-il de PostgreSQL avec des jointures de hachage se déversant dans des fichiers temporaires ? Est-ce MySQL/InnoDB où le taux de réussite du pool de mémoire tampon s'effondre pendant les fenêtres de reporting ? Est-ce la virtualisation qui héberge plusieurs VM de base de données se battant pour le même nœud NUMA ?
La réponse change l'achat.
Les travaux de Lenovo sur configurations de mémoire équilibrées pour les serveurs Intel Xeon 6 à deux sockets rappelle utilement que la disposition de la mémoire n'est pas décorative : elle indique qu'une mémoire déséquilibrée peut réduire la bande passante totale de la mémoire jusqu'à 13% d'une configuration équilibrée avec 8 modules DIMM identiques par processeur. La note de Dell sur les Xeon 6 DDR5 indique que les configurations 1DPC peuvent prendre en charge jusqu'à 6400 MT/s, tandis que les configurations 2DPC fonctionnent généralement à 5200 MT/s dans cette famille de plates-formes.
Alors oui, une mémoire plus rapide peut avoir son importance.
Mais acheter des modules DIMM plus rapides et mal répartir les canaux, c'est comme acheter des pneus coûteux et les boulonner sur un essieu tordu. Le reçu semble impressionnant. La machine, elle, ne l'est pas.
| Espace de décision | Une plus grande capacité de mémoire vive est généralement bénéfique dans les cas suivants | La mémoire vive la plus rapide l'emporte généralement dans les cas suivants | Ce que je vérifierais en premier |
|---|---|---|---|
| Bases de données OLTP | Les index et pages chauds ne tiennent pas dans la mémoire | Le taux de réussite de la mémoire tampon est déjà élevé et les attentes de l'unité centrale sont liées à la bande passante de la mémoire. | Taux de réussite du cache tampon, pages lues par seconde, statistiques d'attente |
| Analyses / rapports | Interrogation de la mémoire temporaire ou des données de balayage de manière répétée | Les ajustements de l'ensemble de travail et les balayages sont limités à la bande passante | Déversements de données temporelles, volume de balayage, localité NUMA |
| Serveur SQL | Le pool de mémoire tampon, le cache de plan, les subventions de requêtes ou le cache de stockage de colonnes sont contraints. | L'édition et la charge de travail peuvent utiliser la bande passante | Limite de l'édition SQL Server, mémoire maximale du serveur, statistiques d'attente |
| MySQL InnoDB | Les erreurs du pool de mémoire tampon entraînent des lectures répétées sur le disque | Le pool de mémoire tampon est correctement dimensionné et le stockage n'est plus le goulot d'étranglement. | innodb_buffer_pool_size, lectures sur disque, pression sur les pages sales |
| PostgreSQL | les tampons partagés, le cache du système d'exploitation, la mémoire de travail et les sessions simultanées sont sous-dimensionnés | Le cache est stable et les requêtes sont limitées au niveau de l'unité centrale et de la mémoire. | tampons_partagés, taille_du_cache_effectif, génération de fichiers temporaires |
| Hôtes de base de données virtualisés | Plusieurs machines virtuelles de base de données surchargent la mémoire de l'hôte | L'hôte dispose d'une mémoire suffisante et d'une population de canaux équilibrée | NUMA, ballooning, swapping, réservation par VM |
| Flottes de DDR4 héritées | La plate-forme existante a encore de la vie et a besoin de densité | De toute façon, la plate-forme ne peut pas utiliser une vitesse plus récente | Modèle de serveur, génération de CPU, règles RDIMM/LRDIMM |
| Nouvelles versions de la DDR5 | Le plan de capacité détermine la densité des machines virtuelles ou l'empreinte analytique. | La plate-forme supporte des MT/s élevés dans la configuration DPC choisie | 1DPC vs 2DPC, équilibre des canaux, liste des modules DIMM approuvés |
Je n'aime pas les citations de souvenirs vagues.
Un devis indiquant “64GB DDR4 ECC server RAM” n'est pas suffisant pour un achat sérieux de mémoire pour un serveur de base de données. Je veux le numéro de pièce du fabricant, le rang, l'organisation x4 ou x8, la vitesse, la classe RDIMM ou LRDIMM, l'état testé, les conditions de garantie et la correspondance avec la plate-forme. Sinon, je ne m'intéresse pas à l'approvisionnement. Je m'intéresse à une future réunion de blâme.
Pour les domaines DDR4, j'enverrais les acheteurs dans les Mémoire serveur DDR4 La catégorie DIMM n'est utilisée qu'après avoir vérifié la génération du serveur et les étiquettes actuelles des modules DIMM. Pour les nouvelles densités, la catégorie Mémoire serveur DDR5 est logique, mais seulement si le CPU, la carte mère, le BIOS et les règles de population DIMM prennent en charge la vitesse et la capacité cibles.
Mais ne vous arrêtez pas à la page de la catégorie.
Avant d'acheter, effectuez une audit de compatibilité de la mémoire du serveur et comparer le module prévu avec la plate-forme réelle. Le guide général de ServerDimm sur achat de mémoire pour serveur est utile parce qu'il considère la mémoire comme une question de compatibilité, de fiabilité, d'approvisionnement et d'adaptation à la charge de travail, plutôt que comme un concours de prix par gigaoctet.
C'est le bon modèle mental.
Voici le processus de terrain que j'utiliserais avant d'approuver le serveur de base de données RAM.
Tout d'abord, il faut mesurer la charge de travail sur un cycle économique complet. Pas dix minutes tranquilles. Pas une démonstration synthétique. Une fenêtre réelle qui inclut les travaux par lots, les pics de rapports, les sauvegardes, la maintenance des index, l'ETL, la réplication et la concurrence des utilisateurs.
Deuxièmement, classez la douleur. Observez-vous des lectures physiques, un effondrement de la durée de vie des pages, des attentes RESOURCE_SEMAPHORE de SQL Server, des fichiers temporaires de PostgreSQL, des manques dans le pool de mémoire tampon de MySQL, une activité de swap Linux, un déséquilibre NUMA ou une saturation de l'espace de stockage ? Des symptômes différents indiquent des problèmes différents.
Troisièmement, la taille de l'ensemble de travail et la marge de manœuvre. Je souhaite généralement disposer de suffisamment de mémoire pour les données et index chauds, le cache du moteur de base de données, la mémoire des requêtes, les connexions, le cache du système d'exploitation et les pics d'activité. Pour un serveur de base de données dédié, laisser le système d'exploitation à bout de souffle est du travail d'amateur.
Quatrièmement, valider l'architecture DIMM. Les modules ECC RDIMM et LRDIMM ne sont pas des substituts occasionnels. DDR4 et DDR5 ne sont pas interchangeables. 2Rx4 et 2Rx8 peuvent se comporter différemment dans les matrices de prise en charge des plates-formes. Et oui, le rang et l'équilibre des canaux ont encore de l'importance alors que tout le monde préférerait parler de capacité.
Cinquièmement, exigez des tests et une garantie claire. Pour les achats de production, je m'appuierais sur les les tests de qualité et l'aide à la garantie avant de faire confiance à un lot bon marché. Si le projet est important, j'utiliserais également la fonction contact et demande de devis avec le modèle exact du serveur, la génération du processeur, le numéro de référence actuel des modules DIMM, la capacité cible, les marques acceptables et la date de déploiement.
L'ennui permet d'économiser de l'argent.
L'augmentation de la mémoire vive du serveur de base de données est généralement la bonne solution lorsque la charge de travail active ne tient pas aisément dans la mémoire.
Cela inclut les cas où le pool de mémoire tampon de SQL Server est constamment sollicité, où MySQL InnoDB ne peut pas conserver les tables et les pages d'index chaudes, où PostgreSQL crée des fichiers temporaires pour les tris et les jointures, ou où un hôte de base de données virtualisé commence à gonfler la mémoire sous la pression. Une fois que la base de données est obligée de traiter le stockage comme une extension de la RAM, les performances deviennent coûteuses, instables et dépendantes de la charge de travail.
La dure vérité : de nombreuses plaintes concernant la lenteur des bases de données ne sont pas dues à des problèmes d'unité centrale. Il s'agit de problèmes de mémoire et de conception des E/S qui portent un costume d'unité centrale.
La capacité contribue également à la stabilité opérationnelle. Les sauvegardes, la réindexation, l'ETL, les rapports par lots et les événements de basculement n'attendent pas poliment que la charge de travail soit calme. Si le système est dimensionné pour une charge moyenne, il vous mettra dans l'embarras en cas de charge réelle.
Une mémoire vive plus rapide devient la bonne solution lorsque la capacité est déjà suffisante et que le goulot d'étranglement se déplace vers la bande passante ou la latence de la mémoire.
Cela peut se produire dans les systèmes à grand nombre de cœurs, les analyses à grande échelle, l'OLTP en mémoire, les charges de travail lourdes de type "columnstore", les grandes opérations de hachage PostgreSQL qui restent en mémoire, ou les hôtes de virtualisation denses où les bases de données sont réparties sur de nombreux cœurs. Mais je veux d'abord des preuves : Compteurs CPU, télémétrie de la bande passante mémoire, vérifications de la localité NUMA, analyse de l'attente et tests avant/après.
Je n'achète pas la vitesse parce que la brochure indique DDR5-5600 ou DDR5-6400.
J'achète de la vitesse lorsque la plate-forme peut réellement l'utiliser avec la population DIMM prévue et que la charge de travail prouve qu'elle peut l'utiliser. Dans le cas contraire, il est préférable d'acheter moins de modules DIMM plus grands, une disposition 1DPC équilibrée ou un rafraîchissement de la plate-forme plutôt que de remplir chaque emplacement et d'accepter un downclock.
Si vous réglez les performances d'un serveur de base de données, arrêtez de demander “plus de mémoire ou plus de capacité” comme si les deux choix étaient égaux dès le départ.
Posez plutôt la question suivante : La base de données manque-t-elle de mémoire, de bande passante ou est-elle piégée par une mauvaise configuration ?
Pour la plupart des bases de données de production, la séquence est simple : fixer la configuration, ajouter suffisamment de capacité ECC compatible, équilibrer les canaux de mémoire, puis envisager la vitesse. Les besoins en mémoire de SQL Server, le dimensionnement du pool de mémoire tampon de MySQL, les tampons partagés de PostgreSQL et le comportement du cache du système d'exploitation, l'agencement NUMA et les règles de peuplement des DIMM sont autant d'éléments qui passent avant la recherche du module le plus rapide sur une liste de fournisseurs.
Je sais que cela semble moins excitant.
Bien. Les bases de données récompensent une discipline ennuyeuse.
Un serveur de base de données a généralement besoin d'une plus grande capacité de mémoire vive avant une mémoire plus rapide lorsque l'ensemble de données actif, les index, les opérations de tri, les jointures, le pool de mémoire tampon ou les sessions simultanées dépassent la mémoire disponible et imposent des lectures sur disque, la pagination, des déversements temporaires ou des plans d'exécution instables lors des pics de charge de travail. La mémoire plus rapide est importante plus tard, une fois que la base de données n'est plus en manque de mémoire.
En pratique, j'achèterais d'abord de la capacité pour la plupart des systèmes OLTP, des charges de travail mixtes et des hôtes de bases de données virtualisées. Je ne donnerais la priorité à une RAM plus rapide qu'après avoir prouvé que la charge de travail tient déjà dans la mémoire et qu'elle est limitée par la bande passante ou la latence de la mémoire.
Un serveur de base de données a besoin de suffisamment de mémoire vive pour contenir son ensemble de travail à chaud, le cache de la base de données, la mémoire d'exécution des requêtes, les frais généraux de connexion, la réserve du système d'exploitation, les outils de surveillance et la marge de manœuvre de la charge de travail maximale sans paginer ou forcer l'accès répété au disque. Le nombre exact dépend de la taille de la base de données, du modèle de charge de travail, de la concurrence, des paramètres du moteur et des limites de la plate-forme.
Pour une petite charge de travail SQL Server, MySQL ou PostgreSQL, 64 Go peuvent suffire. Pour un système de production plus lourd, 256 Go, 512 Go ou plus peuvent être rationnels. La mauvaise méthode consiste à acheter en fonction de la seule taille du fichier de la base de données.
Une RAM plus rapide ne vaut la peine pour SQL Server que lorsque l'instance dispose d'une mémoire utilisable adéquate, que l'édition peut utiliser la capacité configurée, que les statistiques d'attente et les compteurs de performances montrent une pression sur le débit de la mémoire et que la plate-forme du serveur prend en charge la vitesse DIMM cible dans le cadre de la population de canaux planifiée. Dans le cas contraire, la capacité, la configuration et le comportement du stockage sont généralement plus importants.
Je vérifierais les limites de l'édition SQL Server, la mémoire maximale du serveur, le comportement du pool de mémoire tampon, les temps d'attente PAGEIOLATCH, les temps d'attente RESOURCE_SEMAPHORE, l'utilisation du stockage en colonnes et la disposition NUMA avant d'approuver un achat de mémoire axé sur la vitesse.
La meilleure mémoire pour un serveur de base de données est la RAM serveur ECC compatible, généralement RDIMM ou LRDIMM en fonction de la plate-forme, dimensionnée en fonction de l'ensemble des données actives de la charge de travail et installée dans un canal équilibré pris en charge par le fournisseur du serveur. Le meilleur module n'est pas seulement le plus rapide ou le plus grand ; c'est celui que le serveur peut valider et utiliser de manière fiable.
Pour les parcs plus anciens, il peut s'agir de DDR4 ECC RDIMM dans des densités de 32 ou 64 Go. Pour les plates-formes plus récentes, il peut s'agir de DDR5 RDIMM en modules de 64, 96 ou 128 Go, en fonction de la génération de CPU et des règles d'emplacement.
Une trop grande quantité de RAM peut nuire aux performances de la base de données lorsqu'elle est mal configurée, allouée sans marge de manœuvre du système d'exploitation, associée à une mémoire de connexion excessive, installée dans une disposition de canaux déséquilibrée ou utilisée pour justifier le fait d'ignorer la conception des requêtes, l'indexation, le stockage temporaire et les limites du moteur de la base de données. L'augmentation de la capacité n'est utile que si la plate-forme et le logiciel peuvent l'utiliser proprement.
J'ai vu des systèmes surdimensionnés donner de mauvais résultats parce que l'acheteur avait résolu le mauvais problème. La mémoire ne résout pas le problème des index manquants, des mauvaises jointures, de l'espace temporaire surchargé ou du plafond d'édition.
N'achetez pas la mémoire vive d'un serveur de base de données comme s'il s'agissait d'une mise à jour grand public.
Rédigez un bref dossier technique avant de demander un devis : modèle de serveur, génération du processeur, numéro de référence du module DIMM actuel, capacité actuelle, capacité cible, moteur de base de données, version, type de charge de travail, pics de concurrence, symptômes de douleur, classe de module préférée, garantie attendue et fenêtre de déploiement.
Utilisez ensuite ce dossier pour trouver de la mémoire ECC compatible, confirmer si DDR4 ou DDR5 est la bonne solution, et demander des conditions de test et de remplacement avant d'envoyer le bon de commande.
L'étape suivante est simple : vérifiez la charge de travail, lisez les étiquettes des modules DIMM installés, confirmez les règles de la plate-forme et demandez de la mémoire en vous basant sur des preuves, et non sur des espoirs.
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
