J'ai SQL Server 2014 avec mémoire max défini sur 6 Go (la mémoire physique est de 8 Go).
Le Mémoire du serveur cible est parfois de 6 Go, puis retombe à Mémoire totale du serveur (environ 5,3 Go, n'atteint jamais 6 Go). J'ai utilisé commit_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 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 expliqueriez-vous 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 taskmanager pendant les lectures:
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 uniquement puisse 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 mémoire maximale du serveur à 6 Go et 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é en dehors de SQL Server sur une machine Windows, est trop peu de mémoire fournie au système d'exploitation. 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).
Mémoire du serveur cible signifie 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 max server memory sur 6 Go. Il essaie de consommer toute la mémoire à laquelle il est autorisé.
Mémoire totale du serveur est ce que SQL Server est actuellement capable 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 tente 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 annea pour vérifier si une notification de mémoire faible a été signalée. Je dois ajouter DMV sys.dm_os_ring_buffer n'est pas 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 expliqueriez-vous 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 cherchez 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 de lire également SQL Server a-t-il besoin de plus de RAM pour savoir combien RAM SQL Server a besoin et si SQL Server est confronté à 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 mémoire tampon, alors oui SQL Server estime que les pages doivent être déplacées car elles ont 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 de SQL Server. Il ne vous donne pas toujours la valeur correcte, en particulier lorsque le compte de service SQL Server dispose du privilège verrouiller les 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 exécuté 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). Le RAM est en fait de la mémoire physique utilisée ou de la mémoire engagée. Une partie du processus SQL Server est également paginée sur le disque et qui constitue une mémoire virtuelle ou un fichier d'échange et donc si vous allez voir TOTAL mémoire 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 physique RAM ou mémoire engagée) utilisée. C'est la raison pour laquelle les deux sont différents. Si vous voir la première colonne réelle est la mémoire physique utilisée et l'autre est la mémoire virtuelle engagé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 à travers DBCC MEMORYSTATUS
Et 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 de Christian Bolton séminal Professional SQL Server 2008 Internals and Troubleshooting :
MSSQL$<instance >:Memory Manager\Total Server Memory (KB)
:
Ceci indique la taille actuelle du pool de tampons.MSSQL$<instance >:Memory Manager\Target Server Memory (KB)
:
Ceci 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 augmenter le pool de mémoire tampon en raison de la pression de la mémoire, auquel cas vous pouvez approfondir votre recherche.