web-dev-qa-db-fra.com

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 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:

waittype

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 provenant de dm_exec_query_resource_semaphores et sys.dm_exec_query_memory_grants dmv's

dmvserror

Donc, d'après les informations collectées ci-dessus et par SP_Blitz, le sémaphore des ressources semble être le problème.

La mémoire "target_memory_kb" est-elle affectée aux identifiants de sémaphore de ressource trop bas, par rapport à 16 Go RAM disponible).

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

sql-serverperformancesql-server-2005
13
KASQLDBA

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 le système d'exploitation pour ces 4 Go également - 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?

  • Basculez vers un système d'exploitation 64 bits (le système d'exploitation que vous utilisez est depuis longtemps hors de prise en charge de toute façon)
  • Basculez vers 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 4 premiers 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.

25
Brent Ozar