tempdbへのハッシュ/ソートの流出の頻度はどのくらいですか？

私たちのエンタープライズアプリケーションは、データストレージにSQL Serverを使用し、主にOLTPシステムです。ただし、アプリケーションの重要なコンポーネントは、重要なOLAPワークロードを生成します。

tempdbへの書き込み待ち時間は約100msです。この傾向は、時間をかけて保持し、ALLOW_SNAPSHOT_ISOLATION投入されるオフ。私たちはこれに関して問題のトラブルシューティングを行っていますが、これまでに見つかった唯一の興味深いことは、tempdbへのハッシュとソートの流出が非常に多いことです。これはOLAPワークロードによるものだと思います。

質問

流出の頻度はどの程度ですか？どれか？1秒あたりの流出回数は？予備データによると、毎秒約2回のハッシュ流出と1分あたり25回のソート流出があります。

この流出の頻度が、tempdbの書き込み待ち時間が長い主な原因である可能性はありますか？

その他の情報

コアの数ごとに推奨されているように、tempdbには複数のファイルを使用しています。tempdbファイルはRAID 1 + 0 SAN（高性能SSDを搭載）上にありますが、これはメインのDBデータおよびログファイルと同じデバイスです。tempdbファイルのサイズは、非常にまれに大きくなるほど大きくなっています。トレースフラグ1117または1118は使用していません。別の変数は、このセットアップが、すべて中程度から高い負荷を経験する多くの異なるデータベースで共有されていることです。

100ミリ秒の書き込みレイテンシは、MSDN、SQLスキル、その他のサイトで見つかったtempdb書き込みレイテンシの許容範囲よりもはるかに大きくなっています。ただし、他のデータベースの書き込みレイテンシは良好です（10ミリ秒未満）。他の統計に基づいて、tempdbを特に内部オブジェクトに対して頻繁に使用しているようです。したがって、アプリケーションが内部オブジェクトを非常に多く使用している理由を調べるために掘り下げています。

私たちのプラットフォームには、さまざまな形で現れる実際のパフォーマンスの問題があります。私たちはパフォーマンスカウンターを監視し、DMビューを確認し、アプリの動作を分析して、システムのリソース使用特性を掘り下げようとしています。流出はメモリ内ではなくディスク上で実行されるため、流出は劇的な悪影響をもたらすことがわかっているため、現時点では流出に焦点を当てています。また、流出の数は非常に多いようですが、人々が「高」と見なしていることについて何らかの情報を入手したいと考えていました。

この流出の頻度が、tempdbの書き込み待ち時間が長い主な原因である可能性はありますか？

はい、それは可能です。ただし、それは通常、スピルの平均サイズ、およびそれら自体の深さ（つまり、再帰ハッシュスピル、マルチパスソート）であり、頻度自体よりも重要です。

SQL Serverは、tempdbのプレッシャーのさまざまな要因のトラブルシューティングに役立つさまざまなメトリックとDMV情報を提供します。これらの多くは、Microsoftの技術記事「SQL Server 2005でのtempdbの操作」で説明されています（2005以降のすべてのバージョンに適用） ）。

そのドキュメントに含まれているガイダンスと診断クエリを使用して、tempdbの圧力の主な原因の特定を開始できるはずです。ALLOW_SNAPSHOT_ISOLATIONが有効になっていないという理由だけで、バージョンストアのアクティビティなどを無視しないでください。スナップショット分離の他に、多くの機能がバージョンストア（トリガー、MARS、RCSIなど）を使用しています。

並べ替えとハッシュの流出が高レベルで重大であることが判明した場合は、おそらくこれについて特定の監視を設定する必要があります。SQL Serverのバージョンによって多少異なりますが、これは必ずしも簡単なことではありません。ソートとハッシュのスピルをそれらを引き起こした特定のクエリに関連付けるには、イベント通知または拡張イベントが必要です。SolidQの記事「ソート警告の特定と解決」には、一般的な原因の解決に関する詳細といくつかの優れた一般的なアドバイスが含まれています。

また、ストレージチームと協力して、ワークロードに起因する高レイテンシの大きさ、他の共有用途によるもの、および再構成のためのオプションを特定する必要があります。SQL Serverのメトリックの分析は、SANの担当者が提供できるすべてのメトリックと同様に、この説明に役立ちます。