web-dev-qa-db-ja.com

SQL Serverラッチとそのパフォーマンス問題の兆候

データベース（SQL 2008）、特に1つのパフォーマンスカウンター、SQLServer：Latches\Total Latch Wait Time Total Latch Wait Time（ms）の潜在的なパフォーマンスの問題を理解しようとしています。 DBの応答時間が遅くなっていることがわかります。これと一致する唯一の相関スパイクは、総ラッチ待機時間とラッチ待機/秒のスパイクです。ディスクIO、CPU使用率、またはメモリに特定のボトルネックは見られません。

SQLServerラッチの一般的な説明は、それが軽量ロックであるということですが、ラッチとは何か、それがロックとどのように異なるのか、そして私が見ているそれらのどれが大量であるのかについて、より詳細に理解しようとしていますの指標。

sql-serverperformancesql-server-2008locking
14
duckworth

以前のベースラインと比較して、 sys.dm_os_latch_stats を調べて、どのタイプのラッチが競合タイプと待機タイプを増やしているかを確認することをお勧めします。

BUFFERタイプのラッチにスパイクが見られる場合は、同じページを変更するために競合する更新によって駆動されていることを意味します。他の種類のラッチもMSDNで簡単に説明されており、問題の根本的な原因に向かって案内することができます。 「内部使用のみ」とマークされている場合、NDAの危機に瀕していることの詳細な説明として、MSでサポートケースを開く必要があります。

sys.dm_os_wait_stats も確認する必要があります。 PAGELATCH_*の増加が見られる場合、それは上記のBUFFERタイプのラッチと同じ問題であり、同じページを変更しようとしたときの競合、別名です。 更新ホットスポットとして。 PAGEIOLATCH_*の増加が見られる場合、問題はI/Oサブシステムであり、必要なときにページをメモリにロードするのに時間がかかりすぎます。

9
Remus Rusanu

これは、おそらくプロのDBAにとって本当に基本的なエラーです...しかし、これは私が高ラッチ問題で見つけたものであり、このスレッドは検索結果で非常に上位にランク付けされます。他の人の役に立つかもしれないことを少し共有したいと思いました。

nUMAメモリアーキテクチャを使用する新しいデュアル/マルチプロセッササーバーでは、並列処理の最大度合いを、プロセッサごとの実際のコア数に設定する必要があります。この例では、それぞれ4コアのデュアルキセノンがあり、ハイパースレッディングでは、SQLからは16の論理プロセッサのように見えます。

この値をデフォルトの0から4にロックすると、一部のクエリの高ラッチがすぐに削減されます。

私たちのラッチは、場合によっては1000ms +から最大30,000msを実行しました。

11
michael x

このブログからの引用：

sys.dm_db_index_operational_statsを使用：

SELECT 
    OBJECT_NAME(object_id)
    ,page_latch_wait_count
    ,page_latch_wait_in_ms
    ,tree_page_latch_wait_count
    ,tree_page_latch_wait_in_ms  
    ,Page_io_latch_wait_count
    ,Page_io_latch_wait_in_ms
FROM sys.dm_db_index_operational_stats (DB_ID(), NULL, NULL, NULL)

sys.dm_os_latch_statsを使用：

SELECT * FROM sys.dm_os_latch_stats  
WHERE latch_class = 'buffer'
0
Anvesh