Combien RAM doit avoir SQL Server
J'ai une base de données qui prend 500 Go, j'ai remarqué que mon ple est faible même si j'ai 100 Go de RAM. J'ai cherché dans google pour trouver les raisons de cela et j'ai trouvé des requêtes intéressantes. J'ai une requête qui s'exécute sur une très grande table même si elle utilise un index clusterisé, elle provoque la chute de ple. J'ai vérifié ce qui se trouve dans le pool de tampons avant et après la requête et au moment où la requête est terminée et il semble que la base de données doive libérer de l'espace pour l'index utilisé dans ma requête et après la requête, les anciens index sont chargés dans le pool de tampons. Ma question est de savoir combien de mémoire RAM RAM devrait avoir DB, comment pourrais-je le calculer, si ce devait être la quantité qui me permettrait de garder tous les index utilisés en mémoire à la fois? Ou peut-être devrais-je réduire les données conservées dans les tableaux de sorte que les index seront plus petits?
Chaque fois que vous scannez un gros index (ou une grande table, si vous préférez), ces données doivent être transférées du disque vers la mémoire. Lorsque cela se produit, si le pool de tampons contient des données provenant d'autres objets et n'a pas assez d'espace libre pour accueillir les pages que vous lisez à partir du disque, quelque chose doit être rejeté.
Un PLE faible signifie que ce processus se produit trop souvent, détruisant votre pool de mémoire tampon et écrasant votre sous-système d'E/S.
Quelques façons de l'améliorer:
- Ajoutez plus de RAM. Facile et pas très cher de nos jours. Ne résout pas vraiment le problème, mais peut être une solution acceptable à court terme. Combien de RAM? De quoi contenir la partie active de vos bases de données. Vous seul pouvez dire combien cela représente. Toutes les versions/éditions de SQL Server et Windows ne peuvent pas utiliser la même quantité de RAM, alors assurez-vous que vous n'êtes pas limité par cela.
- Purgez certaines données. Êtes-vous sûr d'avoir besoin de toutes les données que vous y avez?
- Créez des index plus petits. Cela signifie inclure dans vos index l'ensemble minimal de colonnes couvrant vos requêtes. Les analyses volumineuses fonctionnent plus rapidement sur des index plus petits et nécessitent moins de RAM. Le compromis est plus d'espace utilisé sur le disque et plus d'opérations à effectuer lors de la mise à jour de la table.
- Créez des index filtrés. Si vous filtrez souvent sur une condition non sélective courante (par exemple:
active=trueou quelque chose de similaire) un index filtré peut aider à réduire la taille des index. Cela a également un impact sur l'application (certaines restrictions d'options SET pour le faire fonctionner). - Utilisez la compression. Les données sont compressées sur disque et en mémoire, donc la compression
ROW/PAGEpeut être un moyen de réduire la consommation de mémoire. Vous aurez besoin de l'édition Enterprise et vous devrez abandonner un peu de CPU, mais cela en vaut souvent la peine pour les objets énormes. - Utilisez les types de données appropriés: en utilisant
(n)charplus de(n)varcharouintlorsquetinyintest suffisant gaspillera non seulement l'espace disque, mais aussi l'espace du pool de mémoire tampon. Cela inclut les types de données numériques et de caractères: assurez-vous que vous utilisez le bon type/taille/précision/échelle pour vos colonnes de données.
même si j'ai 100 Go de mémoire RAM.
Quelle version et édition de SQL Server utilisez-vous? L'édition standard 2012 (et antérieure) n'utilisera que jusqu'à 64 Go, donc si vous les utilisez, il est inutile d'ajouter plus de mémoire dans cette situation. Même dans les versions ultérieures, la limite est de 128 Go pour l'édition standard. Bien sûr, si vous exécutez une entreprise, ces limites ne sont pas présentes.
J'ai une requête qui s'exécute sur une très grande table même si elle utilise un index clusterisé, elle provoque la chute de ple.
"même s'il utilise un index clusterisé" - s'il s'agit de scanning l'index clusterisé, il lit essentiellement la table entière, donc à moins que la requête ne prenne en compte chaque colonne de chaque ligne pour produire son résultat, alors il y a possibilité de refactoriser la requête et/ou de mettre à jour la façon dont les tables impliquées sont indexées. Nous ne pouvons pas aider plus loin sans détails (idéalement: les définitions de table, y compris les index et les clés, la requête, les plans de requête estimés et réels), nous ne pouvons pas aider davantage là-bas.
Ma question est de savoir quelle quantité de mémoire RAM devrait avoir DB, comment pourrais-je la calculer
C'est une question difficile malheureusement. De nombreux articles importants ont été écrits sur le sujet.
doit-il être un montant qui me permette de conserver tous les index utilisés en mémoire à la fois?
La règle de base est "suffisamment pour que l'ensemble de travail commun soit toujours en mémoire" (dans de nombreux cas, "tous les index utilisés en mémoire" signifient plus ou moins la même chose), qui est généralement un petit multiple de l'ensemble de travail commun. - mais vous pouvez aussi penser à cela dans l'autre sens: comment, pour la même quantité de données, c'est-à-dire "puis-je mieux concevoir mes index et mes requêtes pour réduire le jeu de travail commun requis?". Si vous ne scannez jamais un index ou un tas complet, vous n'avez pas besoin de vous assurer que le lot entier reste dans la RAM.
Ou peut-être devrais-je réduire les données conservées dans les tables afin que les index soient plus petits?
Si vous avez besoin des données, vous avez besoin des données. vous pouvez archiver les anciennes données dans une autre base de données, bien que cela soit généralement fait pour économiser de l'espace et du temps de traitement pour les sauvegardes complètes et ainsi de suite plutôt que pour les problèmes d'exécution: une base de données bien conçue/indexée avec des applications bien comportées ne devrait généralement pas en avoir besoin.
Outre les réponses existantes, vous devrez savoir comment RAM est utilisé par SQL Server.
Supposons que vous ayez une boîte de 100 Go RAM dédiée à SQL Server uniquement. SQL Server utilisera tout cela RAM jusqu'à ce que vous la contraigniez et disons que vous contraignez SQL Mémoire maximale du serveur jusqu'à 94 Go ...
Permet de comprendre comment cette mémoire de 94 Go est utilisée et quels sont les principaux composants qui utilisent cette mémoire.
-- fonctionnant en dessous de DMV me donne la liste totale des composants qui peuvent utiliser ces 94 Go de RAM
select (sum(pages_kb))/1024 as 'sizein_mb',type as 'clerkttype'
from sys.dm_os_memory_clerks
group by type
order by (sum(pages_kb)*128)/1024 desc
sizein_mb clerkttype
92469779 MEMORYCLERK_SQLBUFFERPOOL
2889702 CACHESTORE_OBJCP
786610 CACHESTORE_SQLCP
274682 OBJECTSTORE_LOCK_MANAGER
221056 MEMORYCLERK_SOSNODE
206657 USERSTORE_SCHEMAMGR
186691 USERSTORE_TOKENPERM
125331 USERSTORE_DBMETADATA
84542 MEMORYCLERK_SQLSTORENG
Comme vous pouvez le voir sur la sortie ci-dessus, il existe de nombreux composants qui utilisent la mémoire en ce moment et nous pouvons également voir Buffer Pool est le plus grand consommateur de mémoire, suivi de plan Cache =, gestionnaire de verrouillage ..
Un point important à noter est que les composants ci-dessus ajusteraient la mémoire entre eux. Par exemple, la mémoire utilisée par le cache de plan sera volée du pool de tampons, donc si votre cache de plan est rempli de plans ad hoc, le pool de tampons aura moins de mémoire pour fonctionner et à son tour force les pages sur le disque, ce qui n'est pas bon ..
Maintenant, vous avez compris comment le RAM que vous définissez comme limite est utilisé, il est bon de savoir quels sont les objets qui peuvent utiliser la façon dont les 6 Go RAM vous avez quitté à OS est utilisé ..
Voici les composants qui tirent leur mémoire en 6 Go
1.Os itself
2.Linked servers
3.Extended stored procs
3.third party dlls or addins
4.Database email
4.SSIS
5.SSRS
6.SSAS and so on
Maintenant que vous avez compris comment SQL utilise la RAM, vous pouvez facilement prendre une décision et commencer à résoudre les problèmes en cas de problème.