it-swarm.com.de

So lösen Sie die Wartetypen RESOURCE_SEMAPHORE und RESOURCE_SEMAPHORE_QUERY_COMPILE auf

Wir versuchen, die Hauptursache für langsam laufende SQL Server-Abfragen herauszufinden, die Daten aus einer Datenbank mit einer Größe von 300 GB abrufen/abrufen, die auf einem Server mit der folgenden Konfiguration gehostet wird:

Windows Server 2003 R2, SP2, Enterprise Edition, 16 GB RAM, 12 CPU 32 Bit

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

Wir haben das Unternehmen bereits über das Upgrade auf 64-Bit informiert, das über einen Monat dauern würde.

Für das aktuelle Problem versuchen wir jedoch, die Daten zu erfassen, wenn wir den Speicherdruck auflösen oder schließlich zu einer Schlussfolgerung zur Erhöhung des Arbeitsspeichers gelangen können.

Abgeschlossene Aktion: Neuindizierungs- und Aktualisierungsstatistiken sind für diese Datenbank geeignet.

Wie unten gezeigt, haben wir in den letzten 5 Tagen den Semaphor-Wartetyp bemerkt, der während der Ladezeiten ausgeführt wurde:

waittype

Einige Informationen nach den folgenden Abfragen: Puffergröße = 137272

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

und Semaphorenspeicher = 644024 pro unten stehender Abfrage

 SELECT SUM(total_memory_kb)
FROM sys.dm_exec_query_resource_semaphores

Unten finden Sie weitere Informationen aus dm_exec_query_resource_semaphores und sys.dm_exec_query_memory_grants dmv's

dmvserror

Von oben gesammelte Informationen und pro SP_Blitz-Daten Ressourcen-Semaphor scheint also das Problem zu sein.

Ist der für die Ressourcen-Semaphor-ID zugewiesene Speicher 'target_memory_kb' zu niedrig im Vergleich zu 16 GB RAM verfügbar).

Hinweis * pro Analyse bei 8-stündigem Lauf ist 'target_memory_kb' immer unter 1 GB, verglichen mit 16 GB verfügbar?

was könnte das Problem hier sein und wie kann es gelöst werden?

Vielen Dank

13
KASQLDBA

Oh Gott, ich habe hier schlechte Nachrichten.

Unter einem 32-Bit-Betriebssystem verwendet SQL Server nur die ersten 4 GB Speicher für Abfrage-Arbeitsbereiche. (Und es kämpft auch gegen das Betriebssystem um diese 4 GB - alle anderen laufenden Apps konkurrieren ebenfalls um diesen Speicher.)

4 GB klingen vielleicht nach viel, aber es ist relativ einfach, eine Abfrage zu schreiben, die mehrere GB Speicher benötigt, um ausgeführt zu werden. Wenn genügend Abfragen genügend Speicher erfordern, wartet SQL Server mit RESOURCE_SEMAPHORE, da Abfragen nicht genügend Speicher zum Starten erhalten können. RESOURCE_SEMAPHORE_QUERY_COMPILE bedeutet, dass sie nicht einmal genug Speicher bekommen können, um einen Ausführungsplan zu erstellen - und ja, das ist ziemlich schlecht.

Wie können Sie das Problem beheben?

  • Wechseln Sie zu einem 64-Bit-Betriebssystem (das Betriebssystem, das Sie ausführen, wird ohnehin nicht mehr unterstützt)
  • Wechseln Sie zu einem 64-Bit-Build von SQL Server
  • Reduzieren Sie den Speicherbedarf auf dem Server (führen Sie keine anderen Apps auf dieser Box aus, und dies ist besonders wichtig bei 32-Bit-Boxen, da wir nur 4 GB haben).
  • Verwenden Sie mehr Speicher mit den AWE/PAE-Switches - außer dass dies für RESOURCE_SEMAPHORE-Wartezeiten nicht funktioniert, da SQL Server nur diese ersten 4 GB für den Abfrage-Arbeitsbereich verwenden kann
  • Optimieren Sie Abfragen und Indizes so, dass sie weniger Speicher benötigen

Ich zögere sogar, das letzte zu sagen, da das 32-Bit-Problem so schlimm ist und es für die älteren Versionen von SQL Server sehr schwierig ist. Wenn Sie sich in einer aktuellen Version befinden, können Sie den Plan-Cache durchsuchen und Abfragen nach Speicherzuschuss sortieren, die größten Zuschussempfänger finden und diese optimieren. Keine Option für diese alte Antiquität.

25
Brent Ozar