web-dev-qa-db-ja.com

RESOURCE_SEMAPHOREおよびRESOURCE_SEMAPHORE_QUERY_COMPILE待機タイプを解決する方法

以下の構成のサーバーでホストされている、サイズが300 GBのデータベースの1つからデータをヒット/フェッチする、実行速度の遅いSQLサーバークエリの根本的な原因を解明しようとしています。

Windows Server 2003 R2、SP2、Enterprise Edition、16 GB RAM、12 CPU 32ビット

SQL Server 2005、SP4、Enterprise Edition、32ビット。

1か月以上かかる64ビットへのアップグレードについては、すでにお知らせしています。

しかし、現在の問題については、メモリプレッシャーを解決できるか、最終的にRAMを増やすという結論に達した場合に、データを収集しようとしています。

完了したアクション：インデックスの再作成と統計の更新は、このDBに適切です。

以下に示すように、ロード時間中に実行された過去5日間のセマフォのwaittypeに気づきました。

waittype

以下のクエリの後のいくつかの情報：バッファーのサイズ= 137272

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

およびセマフォメモリ=クエリごとに644024

 SELECT SUM(total_memory_kb)
FROM sys.dm_exec_query_resource_semaphores

以下は、dm_exec_query_resource_semaphoresおよびsys.dm_exec_query_memory_grants dmv

dmvserror

したがって、上記の情報が収集され、SP_Blitzデータごとにリソースセマフォが問題のようです。

メモリ 'target_memory_kb'に割り当てられているリソースセマフォIDは、16 GBと比較して低すぎますかRAM利用可能です。

注* 8時間実行の分析ごとに、「target_memory_kb」は常に1 GB未満ですが、16 GBが利用可能ですか？

ここで問題になる可能性があるものと解決方法、提案してください

ありがとう

sql-serverperformancesql-server-2005
13
KASQLDBA

ああ、良かった。ここに悪い知らせがある。

32ビットOSでは、SQL Serverは最初の4 GBのメモリのみをクエリワークスペースなどに使用します。 （そして、それはその4GBのOSとも戦っています-他の実行中のアプリもそのメモリをめぐって競合します。）

4GBのように聞こえるかもしれませんが、実行するために数GBのメモリを必要とするクエリを書くのは比較的簡単です。クエリが十分なメモリを要求すると、SQL ServerはRESOURCE_SEMAPHORE待機をスローします。これは、クエリを開始するために十分なメモリを取得できないためです。 RESOURCE_SEMAPHORE_QUERY_COMPILEは、実行プランをコンパイルするのに十分なメモリを取得することさえできないことを意味します-ええ、それはかなり悪いです。

それでは、どのように修正しますか？

  • 64ビットOSに切り替えます（実行しているOSはサポートが長くなります）
  • SQL Serverの64ビットビルドに切り替える
  • サーバーのメモリ要求を減らします（このボックスで他のアプリを実行しないでください。32GBのボックスでは上限が4 GBなので、これは特に重要です）
  • AWE/PAEスイッチでより多くのメモリを使用する-ただし、SQL Serverはクエリワークスペースに最初の4GBしか使用できないため、RESOURCE_SEMAPHORE待機では機能しません
  • クエリとインデックスを調整して、必要なメモリを減らす

32ビットの問題はひどいので、SQL Serverの古いバージョンでは本当に難しいので、最後の1つを言うのもためらいます。現在のものを使用している場合は、プランのキャッシュを調べ、クエリをメモリの付与によって並べ替え、許可の最大の受信者を見つけ、それらを調整できます。ただし、この古いアンティークのオプションではありません。

25
Brent Ozar