J'ai un seul nœud SQL2012 SP4 exécutant plusieurs bases de données.

Le serveur dispose de 20 Go de mémoire disponible, 14 Go alloués à SQL (rien d'autre ne fonctionne sur la box).

Toutes les quelques minutes, SQL vide tout le cache du tampon. L'espérance de vie de la page atteint zéro, les descripteurs de cache de tampon montrent qu'il n'y a rien dans le cache.

J'ai jeté un coup d'œil aux notifications du moniteur de ressources et les notifications rebondissent de haut / stable / bas toutes les quelques millisecondes:

RESOURCE_MEMPHYSICAL_HIGH RESOURCE_MEM_STEADY RESOURCE_MEMPHYSICAL_LOW

Avec des horodatages distants de plusieurs millisecondes. Le PLE est essentiellement un motif en dents de scie.

J'ai déjà vu cela se produire avec SQL2012 SP1 et cette question:

Les pages libres de SQL Server 2012 dans le cache de tampon ne sont pas utilisées

Semble être un problème similaire, même si j'ai déjà mis à jour le SP4.

J'ai essayé d'activer LPIM pour le compte de service et j'ai essayé de jouer avec le paramètre de mémoire maximale. L'abaissement de la mémoire maximale semble avoir provoqué un vidage plus fréquent du cache de tampon.

Des idées de quoi vérifier ensuite?

La charge de travail du serveur n'est littéralement rien (je fais défiler les listes d'éléments dans un système ERP et cela atteint environ 40 à 50 Mo avant que le cache ne redescende).

C'est intéressant parce que j'ai effectué une mise à niveau à partir du SP1 pour essayer de résoudre ce problème - le cache atteignait environ 500 Mo. Depuis lors, j'ai baissé le paramètre de mémoire maximale à 14 Go, ce qui semble avoir aggravé la situation.

Je me demande si Windows panique et envoie des notifications incorrectes pour la pression de la mémoire sur SQL - il s'ensuit que le serveur avec une mémoire maximale définie sur illimitée semble fonctionner correctement, mais ne remplit jamais le cache de plus de quelques centaines de Mo - mais maintenant, il arrive à peine à 50 ...

Plus d'infos: pour ceux qui ont demandé

Nombre de coeurs: 4

Taille de la base de données: 80 Go

Le journal des erreurs indique: A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): 247928, committed (KB): 495656, memory utilization: 50%.

Résultats de l'exécution de scripts à partir de ce lien: https://www.sqlskills.com/blogs/jonathan/identifying-external-memory-pressure-with-dm_os_ring_buffers-and-ring_buffer_resource_monitor/

Je ne sais pas comment les interpréter - il semble qu'il y ait à la fois une pression de mémoire interne et externe.

Encore plus d'informations:

Il s'agit d'un invité Hyper-V assis sur un hôte avec 96 Go de RAM total dont environ la moitié est allouée aux invités.

Les symptômes semblent similaires à ceci:

SQL Server 2012 x64 - ne peut pas allouer en toute sécurité plus de 50% de RAM

Cependant, lorsque j'ai alloué 14 Go à SQL, les symptômes se sont déclenchés immédiatement (à peine 3 Go de mémoire du serveur ont été engagés)

Hier soir, j'ai fait passer la mémoire invité à 32 Go et le problème a disparu, mais je ne vois que 14 Go de mémoire totale du serveur (et l'entreprise qui gère la base de données est occupée ce matin et c'est à ce moment-là qu'ils ont généralement leurs problèmes de performances).

Actuellement, environ 8 à 9 Go de données dans le cache semblent stables.

Il semble suggérer que 20 Go suffisent pour la charge de travail de cette boîte. Je suis content de le laisser avec 32 Go pour l'instant, mais j'aimerais vraiment aller au fond des choses afin que je puisse mieux configurer les machines virtuelles / SQL.

Je continuerai à creuser et à mettre à jour si je trouve la réponse!

Encore plus d'informations:

Je n'ai pas redémarré SQL après avoir activé LPIM (ne réalisant pas que c'était une exigence) mais j'ai laissé ce paramètre activé et redémarré pour mettre à niveau la mémoire alors maintenant je ne sais pas si l'augmentation de la mémoire ou LPIM a atténué les problèmes.

Sautera ce soir lorsque le serveur sera inactif et vérifiera à nouveau à quoi il ressemble à 20 Go.

Encore plus Plus d'informations:

Actuellement, le serveur fonctionne bien avec 32 Go alloués et nous n'avons pas vu le problème depuis. Si cela se reproduit, je reviendrai sur cette question et continuerai à creuser.

Actuellement, cela reste un mystère, mais je pense que je ne masque que les problèmes pour le moment.

Bien que vous semblez avoir résolu le problème vous-même, voici un résumé des informations pertinentes concernant la solution.

Options de configuration du serveur de mémoire du serveur

Microsoft écrit dans son article Options de configuration du serveur de mémoire serveur (Microsoft | SQL Docs) pour la section Définition manuelle des options de mémoire

_{(c'est moi qui souligne )}

En outre, la définition d'une valeur min_server_memory est essentielle dans un environnement virtualisé pour garantir que la pression de la mémoire de l'hôte sous-jacent n'essaye pas de désallouer la mémoire du pool de tampons sur une machine virtuelle (VM) SQL Server invitée au-delà de ce qui est nécessaire pour des performances acceptables.

La section concernant les pages verrouillées en mémoire (même document) a un paragraphe convaincant égal qui se lit comme suit:

_{(c'est moi qui souligne )}

Cette stratégie Windows détermine quels comptes peuvent utiliser un processus pour conserver les données dans la mémoire physique, empêchant le système de paginer les données vers la mémoire virtuelle sur le disque . Le verrouillage des pages en mémoire peut garder le serveur réactif lors de la pagination de la mémoire sur le disque. L'option Verrouiller les pages en mémoire est définie sur ON dans les instances de l'édition standard de SQL Server et plus lorsque le compte disposant des privilèges pour exécuter sqlservr.exe a obtenu le droit d'utilisateur Windows Lock Pages in Memory (LPIM).

La section LPIM poursuit en expliquant que:

_{(c'est moi qui souligne )}

La définition de cette option n'affecte pas la gestion de la mémoire dynamique de SQL Server, ce qui lui permet de se développer ou de se réduire à la demande d'autres commis de mémoire. Lorsque vous utilisez le droit d'utilisateur Verrouiller les pages en mémoire, il est recommandé de définir une limite supérieure pour la mémoire maximale du serveur, comme indiqué ci-dessus.

... et dans un commentaire important qui:

_{(c'est moi qui souligne )}

La définition de cette option ne doit être utilisée que lorsque cela est nécessaire, à savoir s'il existe des signes indiquant que le processus sqlservr est en cours de pagination . Dans ce cas, l'erreur 17890 sera signalée dans le journal des erreurs, ressemblant à l'exemple ci-dessous:

A significant part of sql server process memory has been paged out. 
This may result in a performance degradation. Duration: #### seconds. 
Working set (KB): ####, committed (KB): ####, memory utilization: ##%.  

À partir de SQL Server 2012 (11.x), l'indicateur de trace 845 n'est pas requis pour l'édition standard pour utiliser les pages verrouillées.

Solution

Sur la base des résultats ci-dessus et de vos observations, la solution à votre problème serait de configurer les paramètres suivants:

1. min_server_memory (5-10 Go?) Basé sur votre commentaire:

   Actuellement, environ 8 à 9 Go de données dans le cache semblent stables.

   ... et la recommandation de Microsoft de définir a min_server_memory.

2. max_server_memory (20-32 Go) en fonction de votre observation:

   Il semble suggérer que 20 Go suffisent pour la charge de travail de cette boîte. Je suis content de le laisser avec 32 Go pour l'instant, mais j'aimerais vraiment aller au fond des choses afin que je puisse mieux configurer les machines virtuelles / SQL.

   ... et la recommandation de Microsoft de définir a max_server_memory.

3. Verrouiller les pages en mémoire: activé pour le compte de service SQL Server.
   En fonction de l'entrée ERRORLOG de votre instance SQL Server que vous avez mentionnée et de la référence de Microsoft dans l'article.

   La définition de cette option ne doit être utilisée que lorsque cela est nécessaire, à savoir s'il existe des signes indiquant que le processus sqlservr est en cours de pagination .

Avant de continuer ...

(Un des) avantages d'avoir un environnement virtualisé est que les ressources peuvent / devraient être partagées, et peut-être même sur-engagées. Cependant, l'activation de Lock Pages In Memory (LPIM) peut avoir un impact négatif sur votre environnement Hyper-V, si votre matériel héberge plusieurs instances. Un engagement excessif de RAM pourrait épuiser d'autres instances.

Avant d'envisager de changer tous les leviers, commencez par les paramètres 1. et 2. Si le réglage fin de ces paramètres de mémoire ne fonctionne pas, envisagez d'activer LPIM si vous avez suffisamment de matériel .