SQL Server n'utilise pas toute la mémoire

J'ai SQL Server 2014 avec une mémoire maximale définie sur 6 Go (la mémoire physique est de 8 Go).

La mémoire du serveur cible est parfois de 6 Go, puis revient à la mémoire totale du serveur (environ 5,3 Go, n'atteint jamais 6 Go). Je committed_kb dans sys.dm_os_sys_info pour vérifier la mémoire utilisée par SQL Server.

Lorsque je surveille sys.dm_os_buffer_descriptors , je constate que des pages sont supprimées du cache - mais il reste encore 700 Mo de mémoire. Si rien n'avait besoin de mémoire, comment expliquer le fait que les pages soient supprimées du cache? Je m'attendrais à ce que SQL Server supprime uniquement les pages lorsqu'il a besoin de mémoire.

Les tables temporaires désallouées ne sont pas un problème sur ce serveur. Mon PLE est 3632. Le cache de procédure est de 2182 Mo.

Je m'attendrais à ce que les pages ne soient supprimées que s'il n'y a plus de mémoire, mais j'ai 700 Mo d'espace libre ou suis-je mal compris?

Quelqu'un peut-il essayer d'expliquer ce comportement?

SQL Server lit également à partir du disque, donc je pense que je peux conclure que toutes les pages nécessaires ne sont pas en mémoire.

J'ai fait quelques recherches supplémentaires et j'ai lu une énorme quantité de pages du disque dans la mémoire et j'ai remarqué quelque chose dans le gestionnaire de tâches pendant les lectures:

• La mémoire utilisée est passée de 7,0 Go -> 7,2 Go -> 7,0 Go -> 7,2 Go -> ...
• Sqlservr.exe est passé de 5,3 Go -> 5,5 Go -> 5,3 Go -> 5,5 Go -> ...

C'est comme si Windows ne laisse pas sqlservr.exe atteindre 6 Go.

J'ai exécuté la requête fournie par Shanky:

select
(physical_memory_in_use_kb/1024) Physical_Memory_usedby_Sqlserver_MB,
(locked_page_allocations_kb/1024 )Locked_pages_used_Sqlserver_MB,
(Virtual_address_committed_kb/1024 )Total_Memory_in_MB,--RAM+ Pagefile
process_physical_memory_low,
process_virtual_memory_low
from sys. dm_os_process_memory

Cela a donné le résultat suivant:

Physical_Memory_usedby_Sqlserver_MB: 5247
Locked_pages_used_Sqlserver_MB: 0
Total_Memory_in_MB: 5625
process_physical_memory_low: 0
process_virtual_memory_low: 0

Ce que je ne comprends pas, c'est pourquoi Total_Memory_in_MB n'est pas égal à 6144 (mémoire max)?

Dans sys.dm_os_ring_buffers, j'ai trouvé RESOURCE_MEMPHYSICAL_LOW, donc je pense que Windows manquait de mémoire et SQL Server doit en renvoyer. Mais il y a environ 1 Go de mémoire disponible => pourquoi Windows dit-il qu'il manque de mémoire?

<Record id="13861" type="RING_BUFFER_RESOURCE_MONITOR" time="20635079241">   
   <ResourceMonitor>
        <Notification>RESOURCE_MEMPHYSICAL_LOW</Notification>
        <IndicatorsProcess>0</IndicatorsProcess>
        <IndicatorsSystem>2</IndicatorsSystem>
        <NodeId>0</NodeId>
        <Effect type="APPLY_LOWPM" state="EFFECT_OFF" reversed="0">0</Effect>
        <Effect type="APPLY_HIGHPM" state="EFFECT_IGNORE" reversed="0">85827186</Effect>
        <Effect type="REVERT_HIGHPM" state="EFFECT_OFF" reversed="0">0</Effect>   
   </ResourceMonitor>   
   <MemoryNode id="0">
        <TargetMemory>6050080</TargetMemory>
        <ReservedMemory>67208656</ReservedMemory>
        <CommittedMemory>5423548</CommittedMemory>
        <SharedMemory>0</SharedMemory>
        <AWEMemory>0</AWEMemory>
        <PagesMemory>4975656</PagesMemory>   
   </MemoryNode>   
   <MemoryRecord>
        <MemoryUtilization>100</MemoryUtilization>
        <TotalPhysicalMemory>8387608</TotalPhysicalMemory>
        <AvailablePhysicalMemory>1048452</AvailablePhysicalMemory>
        <TotalPageFile>11142348</TotalPageFile>
        <AvailablePageFile>2887916</AvailablePageFile>
        <TotalVirtualAddressSpace>137438953344</TotalVirtualAddressSpace>
        <AvailableVirtualAddressSpace>137371168056</AvailableVirtualAddressSpace>
        <AvailableExtendedVirtualAddressSpace>0</AvailableExtendedVirtualAddressSpace
   </MemoryRecord> 
</Record>

Mise à jour
Après quelques recherches pour savoir pourquoi il y avait toujours 1 Go de mémoire disponible, je pense avoir trouvé quelque chose.
Est-il possible que SQL Server puisse uniquement allouer de la mémoire libre et que la mémoire disponible soit ignorée? Lors de l'exécution de Process Explorer (Sysinternals), j'ai vu que la mémoire disponible était de 0.

Pour commencer, je dois dire que vous avez défini la mémoire maximale du serveur sur 6 Go et que la mémoire totale est de 8 Go, vous venez donc de laisser 2 Go pour le système d'exploitation, ce qui, dans de nombreux cas, même si rien n'est installé à part SQL Server sur une machine Windows , la mémoire fournie au système d'exploitation est insuffisante. Pour fonctionner correctement, sur un système avec antivirus installé, le système d'exploitation doit disposer d'au moins 4 Go. Je laisse tout de suite 2 Go pour OS et 1,5 G pour AV.

La mémoire du serveur cible est parfois de 6 Go, puis revient à la mémoire totale du serveur (environ 5,3 Go, n'atteint jamais 6 Go).

La mémoire du serveur cible indique la quantité de mémoire requise par SQL Server pour fonctionner correctement dans le cas idéal. La mémoire du serveur cible essaie d'être de 6 Go car vous avez défini la valeur maximale de la mémoire du serveur sur 6 Go. Il essaie de consommer toute la mémoire à laquelle il est autorisé.

La mémoire totale du serveur est ce que SQL Server est actuellement en mesure de consommer. Il s'agit d'une mémoire engagée et sauvegardée par de la RAM physique. C'est 5,5 Go max dans votre cas.

SQL Server essaie d'augmenter sa consommation de mémoire, mais après avoir atteint 5,3 ou 5,5 Go, le système d'exploitation demande à SQL Server de ne pas augmenter sa consommation de mémoire et pourrait en fait signaler une notification de mémoire faible. Cela se produit car le système d'exploitation peut être confronté à une mémoire insuffisante, comme déjà dit ci-dessus. SQLOS répond si le système d'exploitation Windows fait face à une pression mémoire en demandant à ses caches de réduire leur consommation. Vous pouvez interroger le tampon en anneau pour vérifier si une notification de mémoire faible a été signalée. Je dois ajouter que DMV sys.dm_os_ring_buffer est non documenté mais sûr.

Je vois que des pages sont supprimées du cache - mais il reste encore 700 Mo de mémoire. Si rien n'avait besoin de mémoire, comment expliquer le fait que les pages soient supprimées du cache? Je m'attendrais à ce que SQL Server supprime uniquement les pages lorsqu'il a besoin de mémoire.

Si vous recherchez de la mémoire libre, je ne vous suggérerais pas de regarder les DMV sys.dm_os_buffer_descriptors . Le compteur du système d'exploitation Available Mbytes vous indiquera la quantité de mémoire physique, en octets, disponible pour les processus exécutés sur l'ordinateur. Je vous suggère de voir également Qu'est - ce qu'une méthode déterministe pour évaluer une taille de pool de tampons sensible? et aussi lire Est-ce que SQL Server a besoin de plus de RAM pour savoir combien de RAM SQL Server a besoin et si SQL Server fait face à une pression mémoire. D'après ce que vous avez mentionné, si vous êtes sûr que les pages sont supprimées du pool de tampons, alors oui, SQL Server estime que les pages doivent être déplacées car il a besoin d'espace pour accueillir de nouvelles pages. Je ne sais pas comment vous avez calculé les 700 Mo disponibles.

Une autre chose, veuillez ne pas regarder le Gestionnaire des tâches pour la consommation de mémoire SQL Server. Il ne vous donne pas toujours la valeur correcte, en particulier lorsque le compte de service SQL Server dispose des privilèges de verrouillage des pages en mémoire . Dans votre cas, même si SQL Server a une mémoire serveur maximale de 6 Go, le système d'exploitation ne disposant que de 2 Go, ce qui oblige SQL Server à ne pas augmenter sa consommation car 2 Go sont faibles pour SQL Server. Existe-t-il autre chose que SQL Server en cours d'exécution sur le système?

Si vous souhaitez calculer la consommation de mémoire de SQL Server, veuillez utiliser:

select
(physical_memory_in_use_kb/1024) Physical_Memory_usedby_Sqlserver_MB,
(locked_page_allocations_kb/1024 ) Locked_pages_used_Sqlserver_MB,
(virtual_address_space_committed_kb/1024 ) Total_Memory_in_MB,--RAM+ Pagefile
process_physical_memory_low,
process_virtual_memory_low
from sys.dm_os_process_memory

Ce que je ne comprends pas, c'est pourquoi Total_Memory_in_MB n'est pas égal à 6144 (mémoire max).

La colonne Total_Memory_in_MB signifie la mémoire totale utilisée par SQL Server (RAM + fichier d' échange ). La RAM est en fait une mémoire physique utilisée ou une mémoire engagée. Une partie du processus SQL Server est également paginée sur le disque et constitue une mémoire virtuelle ou un fichier d'échange.Par conséquent, si vous voyez la mémoire TOTALE consommée par SQL Server, ce serait la somme de la mémoire physique et du fichier d'échange.

Alors que la colonne Physical_Memory_usedby_Sqlserver_MB est juste la mémoire physique (mémoire sauvegardée par la RAM physique ou mémoire engagée) utilisée. C'est la raison pour laquelle les deux sont différents. Si vous voyez la première colonne réelle, la mémoire physique est utilisée et l'autre est la mémoire virtuelle validée.

Si vous voulez voir la mémoire paginée, ce serait la différence entre Total_Memory_in_MB et Physical_Memory_usedby_Sqlserver_MB .

REMARQUE: la mémoire totale utilisée serait supérieure à la mémoire physique utilisée.

SQL Server utilise beaucoup plus de caches que le cache de tampon, bien que ce soit de loin le plus grand (un exemple évident est le cache de plan). Vous pouvez regarder de plus près la mémoire DBCC MEMORYSTATUSet une variété de DMV. La mémoire cible et la mémoire totale font spécifiquement référence au Buffer Pool / Cache.

Extrait des principes fondamentaux et du dépannage de Christian Bolton Professional SQL Server 2008 :

• MSSQL$<instance >:Memory Manager\Total Server Memory (KB):
  Cela indique la taille actuelle du pool de tampons.
• MSSQL$<instance >:Memory Manager\Target Server Memory (KB):
  Cela indique la taille idéale pour le pool de tampons. Le total et la cible devraient être presque les mêmes sur un serveur sans pression de mémoire qui fonctionne depuis un certain temps. Si Total est nettement inférieur à Target , il est probable que SQL Server ne puisse pas agrandir le pool de tampons en raison de la pression de la mémoire, auquel cas vous pouvez enquêter davantage.