フラッシュストレージでのチェックポイントの低下と15秒のI / O警告

Question

過去2週間、これらのI/O問題の発生とチェックポイントのスローダウンの原因となる可能性のあるものの根本的な原因を突き止めるために取り組んできました。

一見、それは明らかにI/Oサブシステムエラーであるように見え、SAN管理者が原因であると非難されていました。しかし、最近SANをフルフラッシュを利用しますが、今日の時点ではまだエラーが表示されます。待機統計でもその他のメトリックでも、SQLサーバーが原因であるかどうかを確認するために実行するすべてのメトリックが正常に戻ったように見えるので、理由がわかりません。

それは本当に合算しません。また、何か他のものがディスクを噛んでいて、SQL Serverがここで被害を受けている可能性も高いです...しかし、私は何を見つけることができませんか？

DBは可用性グループ内にあり、これらのイベントが発生すると、タイムアウトとともにロールの変更と反転が発生します。

これを理解するための助けがあれば、高く評価されます。さらに詳細が必要な場合はお知らせください。

エラーメッセージ。未満

SQL Serverは、データベース[ABC]（7）のファイル[E：\ MSSQL\DATA\ABC.mdf]で完了するのに15秒以上かかるI/O要求の14212回の発生を検出しました。 OSファイルハンドルは0x0000000000000D64です。最新の長いI/Oのオフセットは、0x0000641262c000です。

SQL Serverは、データベース[XYZ]（7）のファイル[E：\ MSSQL\DATA\XYZ.mdf]で完了するのに15秒以上かかるI/O要求が5347回発生しました。 OSファイルハンドルは0x0000000000000D64です。最新の長いI/Oのオフセットは、0x0000506c060000です。

FlushCache：db7：0の平均スループット：0.94 MB /秒、I/O飽和：55144、コンテキストスイッチ98407最後のターゲット未解決：10240、avgWriteLatency 14171 FlushCache：5616 bufをクリーンアップし、248687ミリ秒で3126書き込み（3626の新しいダーティbufを回避）、db 6：0平均スループット：0.18 MB /秒、I/O飽和：10080、コンテキストスイッチ20913最後のターゲット未解決：2、avgWriteLatency 3

30分間の仮想ファイルの統計情報は次のとおりです。

そして統計も待つ：

システムアーキテクトからのメモは次のとおりです。

I/O負荷の高いワークロード（DBなど）のワークロードを分離して、ホストごとに1つだけになるようにします。現在のホストの仕様は、16コアのXeon E5-2620（2ソケット）、512GB、およびストレージ用の2x10G相互接続を備えたDell R730です。他のVMクラスターでもホストでもこれらの問題は発生していません。VMとワークロードのストレージはPure FA-x20にあります。

一般的なシステム情報：

SQL Server 2012 sp3-cu9（エンタープライズ版）
合計RAM：128 GB
合計DBサイズ：1 TBに近い

Sean Gallardy · Answer

過去2週間、これらのI/O問題の発生とチェックポイントのスローダウンの原因となる可能性のあるものの根本的な原因を突き止めるために取り組んできました。

いいですね。ミニフィルターとストーポートトレースを収集して切り取りましたか？もしそうなら、それは何を示しましたか？

一見、それは明らかにI/Oサブシステムエラーであるように見え、SAN管理者が原因であると非難されていました。しかし、最近SANをフルフラッシュを利用しますが、今日の時点ではまだエラーが表示されます。待機統計でもその他のメトリックでも、SQLサーバーが原因であるかどうかを確認するために実行するすべてのメトリックが正常に戻ったように見えるので、理由がわかりません。

ここで2つの異なる領域について説明します。

1つ目は、SQL Server自体が実際にI/Oを実行せず、通常のWindows APIを使用してWindowsにポストすることです。それがReadFile、WriteFile、またはそれらのベクトル化されたI/Oであるかどうかは、すべてWindows次第です。 SQL Serverは保留中のI/Oのリストを保持し、完了していない場合はそのI/Oをさまざまなタイミングで確認してステータスを取得します。これも、典型的なWindows非同期I/Oモデルを使用して行われます。 GetOverlappedResult Windows APIを使用してステータスをチェックしているため、Windowsによると、I/Oが保留中で完了していないときにメッセージが出力されます。これは、SQL Serverが実際に発言権を持っているわけではなく、Windowsを介して返されるものであることを意味します。

2番目の項目は、すべてがフラッシュで10 Gbファイバーであるからといって、セットアップや構成が正しく行われていない、ドライバー、フィルター、その他のバグや項目がヒットしていない、または物理的に何かが故障しているというわけではありません違う。ただアイデアを得るために：

Windows設定
セットアップされているマルチパスなどのWindowsドライバーと最新バージョン
フィルタードライバー（ご存知のとおり、ディスクデバイス、ウイルス対策、バックアップなど）
ハイパーバイザー（存在する場合）
HBAドライバー
HBAファームウェア
HBA構成
物理ケーブル
ファイバースイッチング
I/Oグループ接続/ SAN /デバイス
SAN /デバイスの構成

それはallであり、SQL Serverでは、SQL Serverがその1つであるtellingそれだけです。

DBは可用性グループ内にあり、これらのイベントが発生すると、タイムアウトとともにロールの変更と反転が発生します。

これは、知っておくと本当に良い情報ですが、必ずしも正確に関連しているとは限りません。フェイルオーバーが発生した場合にのみ発生する場合、問題はさらに改善され、ドライバーなどのように聞こえます。フェイルオーバーは通常、やり直し/取り消しと再同期が発生し、未解決のI/Oが急増する可能性があるため、大量の混合I/Oをスローするのは好ましくありません。

これを理解するための助けがあれば、高く評価されます。

高いIOPを押し込んでいるクエリまたはクエリのセットでない限り、30分のスナップショットは平均の737,465のI/O操作しかなかったように聞こえませんSQL Serverがメッセンジャーであるため、SQL Serverの内部を調べて410 IOPs（特にフラッシュの場合はそれほど高くありません）ではこの問題を解決できません。

まだ収集していない場合は、収集する必要があります。

費やされたミニフィルター時間。これは、他に何もない場合、WPR（XPerf）を介して行うことができます。これは、I/Oがフィルタードライバーで停止している場合に役立ちます。
Storportトレース。これは、私たちが行く途中の最後のストップであり、戻る途中の最初のストップです。これら2つの測定値の間の時間は、Windowsの外部で費やされた時間です...ターゲットと、反対側の速度が遅い可能性がある場所も表示されます（ただし、常に確定しているわけではありません）。

問題の範囲を絞り込んだり、絞り込んだりするのに役立たない場合は、Windows Storageのサポートでチケットを開き、すべてのデータを収集してすべてのユーザーが同じページから開始できるようになっている可能性があります。

Josh Darnell · Answer

待機統計と「その他すべてのメトリック」をチェックしているとのことですが、 PAGELATCHとWRITELOGの待機が多いと思いますか？再確認するために、sys.dm_io_virtual_file_statsを確認しましたか？これらの15秒のI/Oメッセージを取得するときに、そこから始めます。

使用するクエリに関するガイドとして、Erin Stellatoの優れた記事「仮想Filestatsが行うこと、および行わないこと、I/O待機時間について教えてください」を使用してください。 5分または15分ごとに、そのDMVのスナップショットをテーブルに記録します。平均ストール/レイテンシのスパイクを探します。

これらの急上昇中に、読み取り/書き込みの数、または読み取り/書き込みあたりの平均バイト数が増加したかどうかを確認します。 I/Oサブシステムが処理できる以上のトラフィックで溢れているメンテナンスまたはユーザークエリがある可能性があります。これらのクエリを調整するか、メンテナンスタスクを分割するか、別の時刻に移動する必要があります。

SAN管理者と協力して、SANにこれらの時間に関連する「騒々しい隣人」またはエラーがないかどうかを確認してください。 SAN設定を他のSQL Serverボックスと比較します-物理接続レベルでスループットの問題があるか、調整が必要なキャッシュ設定、または必要な更新がある可能性があります設置されるなど.

これらはやや一般的な手順ですが、うまくいけば、次に進むべき方向がわかると思います。

これに関して：

I/O負荷の高いワークロード（DBなど）のワークロードを分離して、ホストごとに1つだけになるようにします...クラスター上の他のVMもホストもこれらの問題は発生しません

ホストでのI/Oワークロードが高いのがSQL Serverだけである場合、SQL Serverだけがこれらの問題を認識することは理にかなっていると思います。ディスクの遅延が発生しています。

Eドライブは、仮想ファイルの統計のスクリーンショットで特に問題のように見えます。そのドライブに何か違いはありますか？

...ストレージ用の2x10G相互接続

あなたはケーブル配線の問題を抱えている可能性があります。それらを取り付け直し、しっかりと接続されていることを確認してください。別の既知の正常なケーブルと交換する可能性があります。上記のように、SANチームにキャッシュ設定およびその他の構成を確認して、このボリューム/ホストと他のSQL Server VMに違いがないかどうかを確認します。