Comment résoudre les types d'attente RESOURCE_SEMAPHORE et RESOURCE_SEMAPHORE_QUERY_COMPILE

Nous essayons de comprendre la cause première des requêtes de serveur SQL à exécution lente qui frappent / récupèrent les données de l'une des bases de données, taille 300 Go, hébergées sur le serveur avec la configuration ci-dessous:

Windows Server 2003 R2, SP2, Enterprise Edition, 16 Go de RAM, 12 CPU 32 bits

SQL Server 2005, SP4, Enterprise Edition, 32 bits.

Nous avons déjà informé les entreprises de la mise à niveau vers 64 bits, ce qui prendrait plus d'un mois.

Mais pour le problème actuel, nous essayons de rassembler les données si nous pouvons résoudre la pression de la mémoire ou finalement arriver à une conclusion pour augmenter la RAM.

Action terminée: les statistiques de réindexation et de mise à jour sont appropriées pour cette base de données.

Comme indiqué ci-dessous, nous avons remarqué le type d'attente de sémaphore pendant les 5 derniers jours, exécuté pendant les heures de chargement:

Peu d'informations après les requêtes ci-dessous: taille du tampon = 137272

SELECT SUM(virtual_memory_committed_kb)
FROM sys.dm_os_memory_clerks
WHERE type='MEMORYCLERK_SQLBUFFERPOOL'

et mémoire sémaphore = 644024 par requête ci-dessous

 SELECT SUM(total_memory_kb)
FROM sys.dm_exec_query_resource_semaphores

Vous trouverez ci-dessous quelques informations supplémentaires dm_exec_query_resource_semaphoreset des sys.dm_exec_query_memory_grantsdmv

Donc, à partir des informations collectées ci-dessus et par SP_Blitz data Resource, le sémaphore semble être le problème.

La mémoire «target_memory_kb» est-elle affectée pour les identifiants de sémaphore de ressource trop faible, par rapport aux 16 Go de RAM disponibles.

Remarque * par analyse sur 8 heures d'exécution 'target_memory_kb' est toujours inférieur à 1 Go, contre 16 Go disponibles?

quel pourrait être le problème ici et comment le résoudre, veuillez suggérer

Merci

Oh, mon Dieu, j'ai de mauvaises nouvelles ici.

Sur un système d'exploitation 32 bits, SQL Server n'utilise que les 4 premiers Go de mémoire pour des choses comme l'espace de travail de requête. (Et il combat également le système d'exploitation pour ces 4 Go - toutes les autres applications en cours d'exécution rivaliseront également pour cette mémoire.)

4 Go peuvent sembler beaucoup, mais il est relativement facile d'écrire une requête qui nécessite plusieurs Go de mémoire pour fonctionner. Lorsque suffisamment de requêtes nécessitent suffisamment de mémoire, SQL Server lance RESOURCE_SEMAPHORE attend car les requêtes ne peuvent pas obtenir suffisamment de mémoire pour démarrer. RESOURCE_SEMAPHORE_QUERY_COMPILE signifie qu'ils ne peuvent même pas avoir suffisamment de mémoire pour compiler un plan d'exécution - et oui, c'est assez mauvais.

Donc comment le répare-t-on?

• Passez à un système d'exploitation 64 bits (le système d'exploitation que vous utilisez est de toute façon longtemps hors de prise en charge)
• Passer à une version 64 bits de SQL Server
• Réduisez les demandes de mémoire sur le serveur (n'exécutez aucune autre application sur cette boîte, et c'est particulièrement critique sur les boîtes 32 bits car nous sommes plafonnés à seulement 4 Go)
• Utilisez plus de mémoire avec les commutateurs AWE / PAE - sauf que cela ne fonctionne pas pour les attentes RESOURCE_SEMAPHORE car SQL Server ne peut utiliser que les premiers 4 Go pour l'espace de travail de requête
• Ajustez les requêtes et les index pour qu'ils aient besoin de moins de mémoire

J'hésite même à dire ce dernier, car le problème 32 bits est si grave, et c'est vraiment difficile sur les anciennes versions de SQL Server. Si vous étiez sur une version actuelle, vous pouvez parcourir le cache du plan et trier les requêtes par allocation de mémoire, trouver les plus gros destinataires d'allocation et les régler. Pas une option sur cette vieille antiquité, cependant.