MS SQL Server - Augmenter la mémoire allouée

Question

Mon problème est que SQL Server prend beaucoup de temps pour augmenter son utilisation de la mémoire pour les instances avec une valeur de TB de RAM, tout en recevant des attentes intermittentes de MEMORY_ALLOCATION_EXT qui ralentissent notre traitement jusqu'à ce que SQL Server atteigne sa mémoire maximale.

Nous avons des instances en cluster de basculement (FCI) de SQL Server 2019 Enterprise Edition avec des téraoctets de mémoire sur les nœuds. Dans les cas d'utilisation habituels, nous n'autorisons qu'une seule instance de SQL Server par nœud, et nous définissons donc la mémoire maximale du serveur près de ~ 85% de la mémoire sur le nœud, mais nous définissons également la mémoire minimale du serveur relativement faible au cas où SQL Server basculerait vers un autre nœud et doit être mis en ligne avec une empreinte mémoire réduite pour ralentir.

• Je suis tout à fait conscient que si je règle la mémoire minimale plus élevée, SQL Server consommera la mémoire en même temps. Il s'avère que SQL Server n'alloue pas la mémoire minimale au démarrage.
• Je suis conscient que SQL Server consommera dynamiquement plus de mémoire du système d'exploitation selon ses besoins et qu'il atteindra finalement la mémoire maximale du serveur.
• Je suis conscient que l'exécution d'une grosse requête ou DBCC checkdb qui extrait beaucoup de données obligera SQL Server à consommer plus de mémoire du système d'exploitation.

Existe-t-il d'autres moyens de forcer SQL Server à augmenter rapidement son utilisation de la mémoire?

Answer 1

Je suis tout à fait conscient que si je règle la mémoire minimale plus élevée, SQL Server consommera la mémoire en même temps.

Non, ce n'est pas correct, la mémoire minimale du serveur n'a rien à voir avec la vitesse à laquelle SQL Server la consommera si elle est définie. La mémoire minimale du serveur signifie la quantité minimale de mémoire, si elle est consommée, après quoi SQL Server ne libérera pas de mémoire en dessous de cette valeur dans des conditions normales si on lui demande de le faire. Une fois que la valeur minimale du serveur est atteinte, SQL Server ne supprime pas ses caches et ne libère pas de mémoire en dessous de cette valeur.

Je suis conscient que SQL Server consommera dynamiquement plus de mémoire du système d'exploitation selon ses besoins et qu'il atteindra finalement la mémoire maximale du serveur.

Oui correct, juste pour ajouter SQl Server dans certaines conditions peut également consommer de la mémoire supérieure à la valeur spécifiée dans la mémoire maximale du serveur. Vous devriez lire le guide de gestion de la mémoire

Existe-t-il d'autres moyens de forcer SQL Server à augmenter rapidement son utilisation de la mémoire?

Il existe un autre moyen qui force SQL Server à réserver plus de mémoire lors du démarrage et cela s'appelle « grandes pages ». Il s'agit de fonctionnalités d'édition d'entreprise et permet à SQL Server de réserver rapidement de la mémoire libre au démarrage, le compte de service SQL Server doit également avoir des pages verrouillées dans le privilège de mémoire car l'allocation de grandes pages est effectuée par la fonction VirtualAlloc () du système d'exploitation Windows et le système d'exploitation doit avoir plus de 8 Go de RAM, si ces conditions sont remplies automatiquement L'allocation de grandes pages est activée. Une fois activé, il apparaîtra comme ci-dessous dans le journal des erreurs

2009-06-04 12:21:08.16 Server      Large Page Extensions enabled.
2009-06-04 12:21:08.16 Server      Large Page Granularity: 2097152
2009-06-04 12:21:08.21 Server      Large Page Allocated: 32MB

La taille de page normale de la mémoire est de 4 Ko sur le système X64, mais lorsque la grande page est activée, la taille sera de 2 Mo. Notez également que LargePageSupport est activé et utilisé par le moteur même si vous n'activez pas l'indicateur de trace 834. Mais peu de mémoire est utilisée pour cela et la mémoire tampon du pool n'est pas utilisée à moins que l'indicateur de trace 834 ne soit activé. Voir le blog partagé.

Answer 2

SQL Server n'utilisera pas la mémoire pour le pool de tampons (sa plus grande utilisation) tant qu'il n'aura pas besoin de charger des pages à partir du stockage car elles sont référencées. À moins que vous ne fassiez quelque chose d'étrange pour ralentir l'allocation de mémoire ^[†], il est peu probable que votre retard soit celui de la lecture des données allouées afin de les conserver. Je soupçonne qu'en même temps que ces attentes d'allocation de mémoire, vous avez des attentes liées aux E / S correspondantes.

Pour forcer le serveur SQL à charger des choses en mémoire, et donc à allouer de la mémoire si disponible et nécessaire, accédez aux choses afin qu'elles aient besoin d'être chargées. Après avoir démarré votre instance SQL, exécutez une charge de travail en lecture seule afin que l'ensemble de travail commun normal de votre application soit chargé dans le pool de mémoire tampon.

Ne pas simplement SELECT * FROM HugeTablecar cela est susceptible de charger un mauvais équilibre des données (pas le jeu de travail principal des applications), donc le jeu de travail principal devra quand même être chargé à partir du disque / réseau lors du prochain accès afin que vous ayez le même IO retards. De plus, si HugeTablec'est vraiment énorme, SQL Server peut voir que tout ne rentre pas et ne prend pas la peine d'en garder une quantité significative en mémoire de toute façon [‡].

^{[†] Exécution dans une VM sur un hôte surchargé, donc ce qui ressemble à de la vraie RAM est vraiment des pages sur disque?!}

^{[‡] Dans des circonstances normales, vous ne voulez pas qu'une analyse de table / index inattendue sur un objet volumineux évite tout le reste de la mémoire. Une limite sur la quantité conservée d'un objet pour une requête est une optimisation pour essayer d'empêcher que cela se produise).}