1

Nous exécutons la base de données de notre application sur la boîte dédiée exécutant uniquement SQL Server 2005. Ce serveur DB a 32 Go de RAM ... et le fichier de base de données lui-même est seulement 6 Go.SQL Server 2005 "Pin" données en mémoire

Je voudrais forcer plusieurs des tables fortement lues/interrogées dans le tampon de mémoire SQL pour augmenter la vitesse. Je comprends que SQL Server est vraiment bon pour garder les données nécessaires en mémoire cache une fois qu'il est lu à partir du disque ... Mais nos clients préféreraient probablement que leur requête s'exécute rapidement la première fois. "Performances les plus rapides le Deuxième Time" n'est pas exactement un produit phare. En deçà de l'ancienne commande DBCC "Pin Table".

J'ai écrit un processus "CacheTableToSQLMemory" qui traverse tous les index d'une table (non clusterisé &), effectuant un "Select *" dans une table Temp. J'ai planifié l'Agent SQL pour exécuter un Proc de "mettre beaucoup de tables de cache" toutes les 15 minutes pour essayer de garder des pages dans la mémoire.

Cela fonctionne dans une large mesure .. mais même après avoir mis en cache toutes les tables pertinentes d'une requête, l'exécution d'une requête a encore augmenté le nombre de pages mises en cache pour cette table. alors c'est plus rapide la 2ème fois. pensées?

Nous exécutons PAE & AWE. SQL est configuré pour utiliser entre 8 & 20 Go de RAM.

+1

'PAE et AWE set' comme dans 'Je suis toujours en train d'exécuter une instance x86 merde avec 2 Go d'espace d'adressage virtuel'? –

+0

... Je sais ... Je travaille à pousser une mise à niveau du système d'exploitation à travers aussi ... –

+0

Quelle version de Windows? 64-bit j'espère, sinon la réponse est _so_ évident que c'est drôle – smirkingman

Répondre

6

Le goulot d'étranglement x86 est votre véritable problème. AWE peut uniquement servir les pages de données, car elles peuvent être mappées dans et hors des zones AWE, mais toutes les autres allocations de mémoire doivent être entassées dans les 2 Go de l'espace d'adressage virtuel du processus. Cela inclurait chaque pile de threads, tout le code, toutes les données actuellement utilisées par AWE et, surtout, chaque plan en cache, chaque plan d'exécution, chaque jeton de sécurité mis en cache, les métadonnées mises en cache et ainsi de suite. et je ne compte même pas sur CLR, j'espère que vous ne l'utiliserez pas.

Étant donné que le système a 32 Go de RAM, vous ne pouvez pas essayer/3GB et voir même si cela aide, en raison de la réduction totale de 16 Go dans de PAE ce cas qui ferait la moitié de votre RAM invisible ...

Vous devez vraiment passer à x64. AWE peut aider seulement beaucoup.Vous pouvez collecter des compteurs de performance à partir des objets Buffer Manager et Memory Manager et surveiller sys.dm_os_memory_clerks afin d'obtenir une meilleure image du comportement de la mémoire d'instance (où va la mémoire utilisée, qui la consomme, etc.). Je ne m'attends pas à ce que cela vous aide vraiment à résoudre le problème, mais je m'attends à ce qu'il vous donne suffisamment d'informations pour justifier la mise à niveau vers x64.

2

Il n'existe aucun moyen d'épingler des tables en mémoire dans SQL Server 2005. Si SQL Server supprime les tables de la mémoire, c'est parce qu'il y a de la pression de mémoire provenant d'autres parties du système. Puisque votre base de données ne fait que 6 Go, la base de données doit rester en mémoire ... à condition qu'il n'y ait pas d'autres bases de données sur le serveur.

Toutefois, vous pouvez faire quelques opérations pour conserver les données en mémoire. En fonction du niveau de correctif et de l'édition de votre installation SQL Server, vous pouvez utiliser la fonctionnalité lock pages in memory pour vous assurer que la mémoire de SQL Server ne sera jamais renvoyée.

Vous pouvez également modifier l'allocation de mémoire sur le serveur pour qu'elle soit de taille fixe. À moins qu'il y ait quelque chose d'autre sur votre serveur de base de données, vous pouvez définir la mémoire min et max de SQL Server à la même valeur. Cela n'empêchera pas nécessairement que cela se produise dans le futur (c'est une fonction de la façon dont SQL Server est supposé fonctionner) mais cela ne nuira certainement pas à votre SQL Server pour utiliser une quantité de mémoire fixe (si vous n'avez pas d'autre problèmes de mémoire).