Les équipes chargées des ERP et des bases de données rejettent souvent la faute sur l'unité centrale, le stockage ou la “lenteur du langage SQL”, alors que le véritable goulot d'étranglement est plus simple : l'ensemble de travail ne tient plus dans la mémoire. Cet article explique pourquoi SAP HANA, SQL Server, Oracle Database In-Memory et d'autres systèmes d'entreprise dépendent d'une grande capacité de mémoire.
Les CPU rapides mentent.
J'ai vu des équipes d'approvisionnement approuver des processeurs plus récents, des disques NVMe plus rapides et une autre série de “réglages de performance”, tandis que l'équipe de la base de données admet tranquillement que les données actives, le pool de mémoire tampon, le magasin de colonnes ou la charge de travail d'affichage ERP ne peuvent tout simplement plus rester résidents dans la RAM, ce qui signifie que le serveur ne calcule pas lentement ; il attend de manière coûteuse. Pourquoi cela reste-t-il un mystère ?
Voici la dure vérité : charges de travail à forte intensité de mémoire punir les conjectures. Pas avec douceur. Pas à terme. Immédiatement.
Les charges de travail des ERP et des bases de données ne se comportent pas comme un niveau Web sans état. Ils ont un historique. Elles comportent des chaînes de transactions. Elles comportent des index, des verrous, des structures en colonnes, des pressions d'annulation et de rétablissement, des plans d'exécution mis en cache, des requêtes de reporting, des travaux par lots et des pics de fin de mois qui arrivent avec la subtilité d'un camion à travers une paroi en verre.
SAP indique clairement la partie silencieuse dans son Conseils pour le dimensionnement de SAP HANA: Le dimensionnement de SAP HANA tourne principalement autour de la taille de la mémoire principale, et la compression varie suffisamment pour que le dimensionnement soit effectué à l'aide d'outils ou de rapports de dimensionnement SAP, et non pas à l'aide de calculs fantaisistes.
C'est pourquoi je ne demande pas d'abord “Quelle est la quantité de mémoire vive de ce serveur ?.
Je demande : Que faut-il garder en mémoire lorsque l'entreprise est sous pression ?
La plupart des vendeurs vendent de la vitesse parce que la vitesse est facile à imprimer sur un devis.
La capacité est plus moche. Elle oblige à poser des questions inconfortables : Quelle est la taille de l'ensemble de données chaudes ? Quelle est la marge de manœuvre après la réserve du système d'exploitation, la réserve de mémoire de la base de données, les frais généraux de l'HA, les frais généraux de la VM et la croissance ? Utilisons-nous des RDIMM ECC ou des LRDIMM ? Tous les canaux de mémoire sont-ils équilibrés ? Mélangeons-nous les rangs comme des amateurs ?
Mais voici mon opinion après des années d'achat d'infrastructures : si une charge de travail d'ERP ou de base de données utilise la pagination, le cache ou expulse constamment des pages chaudes, un autre niveau de CPU n'est souvent que du métal décoratif.
La documentation de Microsoft sur le serveur SQL indique qu'une chute soudaine de l'espérance de vie des pages peut indiquer une forte utilisation du pool de mémoire tampon, ce qui signifie que la charge de travail n'a pas pu profiter pleinement des données déjà présentes dans la mémoire. Cela n'a rien d'abstrait. C'est la base de données qui agite un drapeau rouge. Surveillance de la mémoire du serveur Microsoft SQL rend cela visible grâce aux mesures du pool de mémoire tampon et au comportement de la mémoire cache.
Ainsi, lorsque quelqu'un demande “Pourquoi les bases de données ont-elles besoin d'autant de mémoire vive ?”, je réponds sans détour : c'est sur les disques que les bases de données vont s'excuser d'avoir été mal dimensionnées.
La bande passante de la mémoire est importante lorsque l'unité centrale traite rapidement de grands volumes de données.
La capacité de la mémoire est importante lorsque l'ensemble des données de travail doit tenir dans la mémoire vive.
Il ne s'agit pas du même problème. Une plateforme DDR5 avec plus de canaux peut déplacer les données plus rapidement, mais si le serveur n'a que 512 Go d'installés et que l'ensemble de travail réel atteint 900 Go pendant la clôture du trimestre, la bande passante ne vous sauvera pas. Vous êtes à court. C'est un point final.
| Type de charge de travail | Ce qui mange la mémoire | Signal de capacité | Mauvaise habitude d'achat |
|---|---|---|---|
| SAP HANA ERP / S/4HANA | Tables à colonnes, magasins delta, structures de compression, vues de calcul, périodes d'activité intense | Mémoire de pointe en fin de mois, en fin d'année ou lors des tests de migration | Achat d'une “utilisation moyenne” au lieu d'une capacité de pointe. |
| SQL Server OLTP | Pool de mémoire tampon, cache de plan, subventions de mémoire, pression tempdb, lectures lourdes d'index | Baisse de l'espérance de vie des pages, nombre élevé de lectures physiques, faible stabilité du cache | Ajout d'une unité centrale avant de corriger la pression du pool de mémoire tampon |
| Oracle Database In-Memory | IM column store, objets analytiques, choix de duplication RAC, hot partitions | INMEMORY_SIZE, population d'objets, comportement des segments froids/chauds | Traiter l'option In-Memory comme de la magie au lieu de dimensionner le magasin de colonnes |
| ERP mixte + Reporting | Tables de transactions, extraits de rapports, requêtes d'entrepôt, travaux par lots | Pics lors de l'actualisation de la BI, de la paie, du MRP, de la facturation, de la clôture. | Dimensionnement pour les utilisateurs diurnes et non pour les fenêtres de traitement par lots |
| Bases de données virtualisées | Mémoire d'invité, réserve de l'hyperviseur, localité NUMA, risque de ballonnement | Contestation des hôtes, déséquilibre NUMA, latence imprévisible | Utilisation excessive de la mémoire parce que la feuille de calcul semble efficace |
Oracle est tout aussi direct à sa manière. Les Documentation Oracle Database In-Memory indique que le magasin de colonnes en mémoire est la fonction clé pour les analyses en temps réel et les charges de travail mixtes, et que pour que les requêtes en bénéficient, le dimensionnement du magasin de colonnes en mémoire est la tâche requise.
Remarquez le modèle.
SAP parle de mémoire de taille. Microsoft montre quand la saturation de la mémoire cache est préjudiciable. Oracle dit que le magasin de colonnes doit être dimensionné. Pourtant, les acheteurs sont toujours obsédés par les UGS de processeurs qui permettent de faire tenir un ensemble de travail de 600 Go dans 384 Go.
Ce ne sera pas le cas.
Les charges de travail des ERP sont des systèmes politiques déguisés en bases de données.
La finance veut une clôture rapide. Les opérations veulent le MRP. Les ventes veulent de la disponibilité par rapport aux promesses. La conformité veut des rapports. Les dirigeants veulent des tableaux de bord. Personne ne veut entendre que le “serveur de base de données” contient en réalité le modèle d'entreprise dans une mémoire volatile.
Les besoins en mémoire des charges de travail ERP sont importants car les données ERP sont relationnelles, historiques, interconnectées et sensibles au temps. Un seul cycle de comptabilisation ou de planification peut concerner les stocks, la tarification, les données des fournisseurs, les soldes des clients, la logique fiscale, les tables de devises, les pistes d'audit et les états des flux de travail. Il ne s'agit pas d'une petite requête bien ordonnée. Il s'agit d'une discussion avec l'ensemble de l'entreprise.
SAP HANA rend cela encore plus explicite car il s'agit d'une base de données en mémoire. AWS conseille aux équipes de déterminer la taille du système pour la migration vers SAP HANA à partir des éléments suivants utilisation maximale de la mémoire, Il recommande même d'effectuer des mesures pendant les périodes de forte charge, telles que les opérations de fin d'année ou les événements commerciaux majeurs. Conseils de dimensionnement pour AWS SAP HANA est utile parce qu'elle dit ce que de nombreuses équipes internes évitent : la mémoire allouée est moins utile que la demande de pointe mesurée.
C'est là que je vois généralement l'erreur d'approvisionnement.
Ils achètent de la capacité pour le mardi normal. L'entreprise échoue le vendredi, jour anormal.
Pour les grandes charges de travail des serveurs de mémoire, je préférerais que les équipes partent d'une plate-forme et d'un plan de module vérifiés : RDIMM ECC validés, LRDIMM lorsque la densité l'exige, règles de population propres et correspondance exacte des pièces. ServerDimm's fournisseur de RAM pour serveur en vrac page s'inscrit dans ce mouvement d'acquisition car elle est axée sur l'approvisionnement en DDR3, DDR4, DDR5, ECC, RDIMM et LRDIMM pour les acheteurs des entreprises et des centres de données. Pour les projets de rafraîchissement, je comparerais les anciens systèmes Xeon Scalable ou EPYC à Mémoire serveur DDR4 et les nouvelles plates-formes à haute densité contre Mémoire serveur DDR5 avant de parler de prix.
Le prix est important. Une mauvaise mémoire coûte plus cher.
La mémoire n'est pas seulement une capacité. C'est un risque.
J'ai vu des équipes traiter l'ECC comme un objet religieux magique. “Il y a un ECC, donc tout va bien”. L'ECC réduit les risques. Il n'efface pas la réalité de la flotte, les modules vieillissants, les modules DIMM marginaux, les problèmes de microprogrammes, une mauvaise validation, une mauvaise manipulation ou un stock de remplacement négligé.
L'étude de terrain de Google, Erreurs de DRAM dans la nature, L'étude a révélé entre 25 000 et 70 000 erreurs par milliard d'heures de fonctionnement par Mbit et plus de 8% de modules DIMM affectés par des erreurs par an. Il ne s'agit pas d'une anecdote de Reddit. Il s'agit de données à l'échelle de la production.
Un document de Carnegie Mellon/Facebook, Réexamen des erreurs de mémoire dans les centres de données de production à grande échelle, Cette étude, qui a porté sur le parc de serveurs de Facebook pendant 14 mois et des milliards de jours-appareils, est exactement le type de données que les acheteurs devraient lire avant de prétendre que le risque de perte de mémoire est théorique.
Et les pannes ne sont pas un théâtre bon marché. L'étude de l'Uptime Institute Analyse des interruptions annuelles 2024 a indiqué que 54% des personnes interrogées ont déclaré que leur dernière panne importante, grave ou sévère avait coûté plus de $100 000, tandis que 16% ont déclaré qu'elle avait coûté plus de $1 million.
Cela change la conversation d'achat.
Une différence de $40 par DIMM semble astucieuse jusqu'à ce que le nœud ERP défaillant se trouve dans un entrepôt de modules “compatibles” que personne n'a testés correctement. C'est pourquoi j'aime placer un article de validation directement dans le parcours de l'acheteur : testé la validation de la mémoire du serveur utilisé Le coût, la garantie et le délai d'exécution font partie de la même conversation que le coût, la garantie et le délai d'exécution.
Je ne fais pas confiance aux calculateurs de RAM génériques pour les charges de travail des ERP et des bases de données.
Je me fie aux pics mesurés, aux fenêtres de charge de travail, aux règles des fournisseurs et aux horribles feuilles de calcul qui indiquent les serveurs exacts, les prises, les emplacements DIMM, les canaux de mémoire, les rangs, les vitesses, les versions BIOS, les systèmes d'exploitation, les versions de base de données et les hypothèses de croissance.
Voici la séquence de dimensionnement que j'utiliserais avant d'approuver la capacité de mémoire pour un ERP ou un hôte de base de données :
L'utilisation moyenne de la mémoire est la façon dont les équipes se mentent à elles-mêmes.
Pour SAP HANA, je veux des pics de mémoire pendant la fin du mois, la clôture du trimestre, la fin de l'année, les migrations à blanc et les pics de rapports. Pour SQL Server, je veux le comportement du pool de mémoire tampon, les lectures physiques, les octrois de mémoire et les baisses de l'espérance de vie des pages. Pour Oracle Database In-Memory, je veux des objets peuplés, le dimensionnement du magasin de colonnes IM et le comportement des segments chauds/froids.
Si l'ensemble de travail ne convient pas, achetez une capacité.
S'il correspond mais que les scans affament les pipelines du CPU, la bande passante, les canaux de mémoire, le placement NUMA et l'architecture du CPU sont plus importants. De nombreuses équipes fusionnent ces éléments en un vague problème de “performances de la RAM” et achètent ensuite la mauvaise solution.
Parce qu'il le peut.
Sur les serveurs multi-sockets, la localité de la mémoire peut transformer une conception de base de données propre en une taxe de latence. Je veux que les modules DIMM soient répartis symétriquement entre les canaux et les sockets. Je veux que le plan de mémoire de la base de données corresponde à la plate-forme physique. Et je veux que les équipes de virtualisation cessent de prétendre que “RAM assignée” et “mémoire locale rapide” sont toujours la même chose.
Une piscine de réserve n'est pas un tiroir de bric-à-brac.
Pour les systèmes d'ERP, de base de données et d'analyse, une véritable stratégie de remplacement signifie des modules approuvés, des spécifications exactes, des stocks testés, des règles de quarantaine et une discipline de réapprovisionnement. Le guide de ServerDimm sur la façon de créer un pool de mémoire de secours pour le serveur est pertinent ici car la planification de la capacité sans la planification du remplacement n'est qu'une demi-politique.
Je ne commencerais pas par la préférence de marque.
Je commencerais par la vérité de la plate-forme.
Pour les charges de travail des bases de données, la meilleure mémoire serveur est celle qui correspond à la génération supportée par le serveur, au type de DIMM, à la disposition des rangs, aux règles de vitesse, au plan de population des canaux, à l'objectif de capacité et à l'exigence de validation. Cela signifie généralement une mémoire ECC RDIMM pour de nombreux hôtes de bases de données classiques et une mémoire LRDIMM lorsque la densité par socket est plus importante que la simplicité.
Voici la liste de contrôle de l'acheteur mal à l'aise :
| Point de décision | Ce que je veux voir | Pourquoi c'est important |
|---|---|---|
| Génération DDR | DDR4-2933/3200 ou DDR5-4800/5600 en fonction de la plate-forme supportée | La mauvaise génération est physiquement et électriquement incompatible |
| Type de module DIMM | ECC RDIMM ou LRDIMM, pas de vague “RAM de serveur”.” | Le temps de fonctionnement de la base de données dépend de la correction des erreurs et de la topologie supportée. |
| Plan de capacité | 25-40% marge de manœuvre au-delà de la crête mesurée pour les systèmes ERP/bases de données sérieux | La croissance, les pics de charge, le basculement et la création de rapports demandent rarement la permission. |
| Équilibre des canaux | Population symétrique sur les canaux de mémoire de l'unité centrale | Évite les pénalités évitables en matière de bande passante et de latence |
| Rang et vitesse | Confirmé par rapport aux règles de mémoire de l'OEM | Les rangs mixtes peuvent downclocker ou limiter les configurations prises en charge |
| Preuves du fournisseur | Dossiers d'essais, numéros de pièces exacts, garantie, discipline en matière d'emballage | “La politique de validation n'est pas ”Pulled working". |
| Stratégie de réserve | Stock d'urgence séparé du stock d'expansion | Empêche qu'une mise à niveau planifiée ne vole l'inventaire de rétablissement de la panne. |
Pour un approvisionnement actif, je pousserais les acheteurs vers un flux de devis qui oblige à la spécificité : modèle de serveur, génération de CPU, carte de mémoire installée, capacité cible, marques préférées, quantités et calendrier de déploiement. C'est exactement le type d'informations que ServerDimm demande par l'intermédiaire de son site web demande de devis pour la mémoire du serveur.
La mauvaise citation dit : “64GB DDR4 server RAM”.”
La bonne citation dit : “64GB DDR4-3200 ECC RDIMM, 2Rx4, plateforme approuvée pour Dell PowerEdge R750, matchched set, testé, quantité requise 192 modules, livraison à Francfort, garantie confirmée”.”
Vous voyez la différence ?
L'un d'entre eux fait des achats. L'autre fait de l'ingénierie avec un bon de commande.
Les charges de travail à forte intensité de mémoire sont des applications dont les performances et la stabilité dépendent principalement d'une mémoire vive suffisante pour contenir les ensembles de données actifs, les index, les caches, l'état des transactions et les objets de travail, de sorte que le système évite les lectures constantes sur disque, la pagination, l'éviction, les pénalités NUMA ou la saturation du cache pendant le traitement critique de l'entreprise.
En clair, ces charges de travail ralentissent lorsque les données dont elles ont besoin ne peuvent pas rester à proximité de l'unité centrale. Les systèmes ERP, SAP HANA, SQL Server, Oracle Database In-Memory, Redis, les plateformes analytiques et les grandes grappes de virtualisation correspondent tous à ce schéma lorsque l'ensemble des données actives dépasse la mémoire installée.
Les bases de données ont besoin d'autant de RAM parce que la mémoire contient les pages de données fréquemment consultées, les index, les plans d'exécution, les magasins de colonnes, les structures de transaction et les données de travail temporaires, ce qui permet aux requêtes et aux processus d'entreprise d'éviter les lectures répétées sur le disque qui ajoutent de la latence, augmentent la pression des E/S et déstabilisent les performances en cas de pic de demande.
C'est pourquoi la capacité de mémoire des charges de travail des bases de données n'est pas seulement un détail matériel. Elle détermine si le système se comporte de manière prévisible pendant les périodes de paie, de facturation, de clôture, d'établissement de rapports et de pics de transactions avec les clients.
Les besoins en mémoire de SAP HANA dépendent de la taille de la base de données source, du comportement de compression, du type de charge de travail, de l'utilisation maximale, du modèle de déploiement et des résultats du dimensionnement SAP. Le dimensionnement responsable doit donc utiliser SAP Quick Sizer, les rapports de dimensionnement SAP, les notes SAP ou l'utilisation maximale mesurée plutôt que des hypothèses génériques de RAM par téraoctet.
La réponse paresseuse est “HANA compresse les données, vous avez donc besoin de moins de RAM”. La réponse professionnelle est “mesurez et dimensionnez la charge de travail réelle”. La compression varie. Le comportement de la charge de travail varie. Les pics d'activité varient.
La capacité de la mémoire est plus importante que la largeur de bande de la mémoire lorsque l'ensemble des données actives de la charge de travail ne peut pas tenir dans la RAM, car aucune largeur de bande supplémentaire ne peut empêcher la pagination, l'éviction du cache, les lectures sur disque ou les pannes hors mémoire si le système n'a pas assez de mémoire installée pour l'ensemble des données de travail réelles.
La largeur de bande de la mémoire devient plus importante lorsque la capacité est suffisante. C'est alors que le nombre de canaux, la vitesse de la DDR5, la localité NUMA et l'architecture de la mémoire du processeur commencent à dominer. La capacité d'abord. Ensuite, la bande passante.
La meilleure mémoire serveur pour les charges de travail des bases de données est une mémoire ECC RDIMM ou LRDIMM validée qui correspond à la plate-forme serveur, à la génération de CPU, aux règles de population DIMM, aux limites de vitesse, à la disposition des rangs, à la capacité cible et aux besoins de fiabilité de la base de données, avec une marge suffisante pour les pics d'utilisation, le comportement de basculement et la croissance future.
Pour de nombreux serveurs, l'ECC RDIMM est la solution par défaut. Pour les systèmes à très haute capacité, les LRDIMM peuvent être nécessaires. La mauvaise réponse consiste à acheter en fonction du seul label de capacité.
Ne demandez pas “plus de mémoire”.”
Demandez un plan de mémoire adapté à la charge de travail.
Vérifiez les pics d'utilisation, confirmez les limites de la plate-forme, définissez les besoins en DDR4 ou DDR5, documentez la prise en charge des RDIMM par rapport aux LRDIMM, équilibrez les canaux de mémoire, réservez une marge de croissance et gardez un stock de rechange testé prêt avant que le prochain incident ERP ou de base de données ne se transforme en problème financier.
Envoyez votre modèle de serveur exact, votre configuration DIMM actuelle, votre capacité cible, le type de charge de travail, la quantité et la région d'expédition par l'intermédiaire de la page d'accueil de ServerDimm. page de devis pour la mémoire du serveur en vrac et obliger la conversation à être spécifique dès le premier courriel. C'est ainsi que les équipes sérieuses achètent de la mémoire pour les charges de travail à forte intensité de mémoire.
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
