web-dev-qa-db-ja.com

RAMの論理読み取りは待機統計またはどこに表示されますか？

SQLOSの実行モデル（RUNNING状態、RUNNABLEキュー、WAITERリスト）に関して、RAM現在進行中のページの論理読み取りがある場合のタスクの状態はどうなりますか？

それがWAITERリストの場合、最も一般的な待機タイプは何でしょうか？

そのような操作にかかる時間をどうにかして測定できますか？

多くの論理読み取りがクエリを遅くし、多くのテーブル/インデックススキャン（すでにバッファプールにある）がクエリを遅くすることを知っています-それらがstatistics/dmvにどのように表示されるか、または他と区別する方法を知りたいだけです「クラシック」待機タイプ。

sql-serverperformancewaitsperformance-tuning
1
jerik1

ある種のリソースを待つ必要がある場合、ワーカーはウェイターリストに登録されます。論理読み取りを待機するリソースはありません。バッファプールがページアウトされていないと仮定すると、データはSQLServerによって管理されているメモリにすでに存在します。多くの論理読み取りを行うクエリは、それらの論理読み取りを行うために多くのCPUを消費するため、低速です。

論理読み取りを実行するときにSQLServerが実行している内部操作を把握したい場合は、論理読み取りによってボトルネックになっているクエリを実行しながら、 perfview またはその他のツールを使用してETWトレースを実行できます。ワークロードにメモリスループットの問題があると思われる場合は、ETWトレースが適切なステップになる可能性があります。これはおそらく当てはまらないことに注意してください。次のデモは、クエリのパフォーマンスの問題に取り組むための間違った方法であることはほぼ間違いありません。

最初に、ほとんどの時間を論理読み取りに費やすと予想されるクエリをまとめます。

DROP TABLE IF EXISTS #215016;

SELECT 1 ID, REPLICATE('Z', 1000) FILLER INTO #215016
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

SELECT t1.ID, t2.ID
FROM #215016 t1
INNER JOIN #215016 t2 ON t1.ID < t2.ID
OPTION (MAXDOP 1, QueryRuleOff BuildSpool);

SQL Serverは、クエリの実行中にCPUのフルコアを使用しました。 10秒のサンプルから取得したperfviewの結果は次のとおりです。

ETW

おそらく、丸で囲まれたメソッド名が関心のあるものです。このクエリでは、SQLServerはCPU時間の約5％をsqlmin!BPool::Getに費やします。これは、実際に論理読み取りを実行することに関係していると思います。その考えを擁護するために、そのメソッドはほとんどの場合sqlmin!BUF::AcquireLatchを呼び出すものです。

enter image description here

クエリ中に取得される共有ラッチの数は、論理読み取りの数とほぼ同じです。ただし、メソッド名はMicrosoftによって文書化されておらず、「論理読み取り」の全範囲がわからないため、これは単なる推測です。

6
Joe Obbish