SQL Serverは、15秒以上かかるI / O要求の発生を検出しました

実稼働SQL Serverには、次の構成があります。

3台のDell PowerEdge R630サーバーを可用性グループに統合3台すべてがRAIDアレイである単一のDell SANストレージユニットに接続されている

時々、PRIMARYで次のようなメッセージが表示されます。

SQL Serverは、データベースID 8
のファイル[F：\ Data \ MyDatabase.mdf]で完了するのに15秒以上かかるI / O要求が11回発生しました。OSファイルハンドルは0x0000000000001FBCです。
最新の長いI / Oのオフセットは0x000004295d0000です。
長いI / Oの継続時間は37397ミリ秒です。

パフォーマンストラブルシューティングの初心者です

ストレージに関連するこの特定の問題のトラブルシューティングで最も一般的な方法またはベストプラクティスは何ですか？このようなメッセージの根本原因を絞り込むには、どのパフォーマンスカウンター、ツール、モニター、アプリなどを使用する必要がありますか？役立つ可能性のある拡張イベント、または何らかの種類の監査/ログがありますか？

同様の設定があり、最近ログでこれらのメッセージに遭遇しました。DELL Compellent SANを使用しています。これらのメッセージを受信したときに確認するいくつかの事項は、解決策を見つけるのに役立ちました

• 警告メッセージが指しているディスクのWindowsパフォーマンスカウンターを確認します。具体的には次のとおりです。
  • 平均ディスク 読み取り時間
  • 平均ディスク 書き込み時間
  • ディスク読み取りバイト/秒
  • ディスク書き込みバイト/秒
  • ディスク転送/秒
  • 平均 ディスクキューの長さ
• 上記は平均です。1つのドライブに多くのデータベースファイルがある場合、これらの平均は結果をゆがめ、特定のデータベースファイルのボトルネックを隠す可能性があります。チェックアウトこの DMVからファイルごとに平均待ち時間を返しポール・S・ランダルからクエリをsys.dm_io_virtual_file_stats。私たちの場合、報告された平均レイテンシは許容範囲内でしたが、カバーの下には、平均レイテンシが200ミリ秒を超える多くのファイルがありました。
• タイミングを確認してください。パターンはありますか？夜の特定の時間に頻繁に発生しますか？その場合、メンテナンスジョブがその時点で実行されているか、ディスクアクティビティを増加させ、IOサブシステムのボトルネックを明らかにする可能性のあるスケジュールされたアクティビティを確認します。
• Windowsイベントビューアーでエラーを確認します。スイッチまたはSANが過負荷になっているか、アプリケーションに適切にセットアップされていない場合、このログにいくつかのメッセージが記録されることがあります。この情報をSAN管理者に伝えてください。私たちのケースでは、1日を通してiSCSI接続エラーを頻繁に受信し、問題を示唆していました。
• SQL Serverコードを確認します。これらのメッセージを受け取ったとき、それがIOサブシステムの問題であるとすぐに考えてSAN管理者に渡すべきではありません。あなたは自分の役割を果たし、データベースを確認する必要があります。大量のデータをめぐって頻繁に実行される本当に悪いクエリがありますか？悪いインデックス？トランザクションログの書き込みが過剰ですか？いくつかのオープンソースクエリを使用して、データベースのヘルスチェックを取得できます。クエリプランの外観を確認する例は、sp_blitzCacheです。
• これらを無視しないでください。今日、あなたは1日に数回それらを受け取っているかもしれません...そして数ヶ月後にあなたのワークロードが増加し、それらが増加し始めるのを監視するのを忘れたとき。これらのメッセージを大量に受信すると、SQL Serverが特定のファイルにアクセスできなくなる可能性があります。tempdbの場合、これは適切ではありません。私たちの場合、SQL Serverがシャットダウンするほどひどくなりました。

私たちのソリューションは、スイッチをSANスイッチにアップグレードすることでした。はい、これらはすべてSQL Serverでカバーすべきポイントです。スイッチを発見した理由は、SQL ServerのWindowsアプリケーションイベントビューアーで毎日約1500のiSCSI pdu切断エラーを受け取っていたことです。そのため、SAN管理者によるスイッチの調査が必要になりました。

アップグレード後すぐに、iSCSIエラーがなくなり、すべてのファイルの平均レイテンシが約50ミリ秒に低下しました。これは、アプリケーションのパフォーマンスの向上と相関していました。これらの点を念頭に置いて、解決策を見つけることができれば幸いです。

これはディスクの問題ではなく、ネットワークの問題です。SANのNを知っていますか？

SANチームに行って、ディスクの速度が遅いことについて話し始めると、待ち時間が0ミリ秒の派手なグラフが表示され、ステープラーが表示されます。

代わりに、SANへのネットワークパスについて質問してください。マルチパスの場合など、速度を取得します。表示される速度について数値を取得します。サーバーがセットアップされたときからベンチマークがあるかどうかを尋ねます。

その後、Crystal Disk Markまたはdiskpdを使用できますをして、これらの速度を検証できます。彼らが並んでいない場合、再び、それはおそらくネットワークです。

また、「FlushCache」と「saturation」を含むメッセージをエラーログで検索する必要があります。これらはネットワーク競合の兆候でもある可能性があるためです。

DBAとしてこれらを回避するためにできることの1つは、メンテナンスと他のデータ量の多いタスク（ETLなど）が同時に実行されないようにすることです。それは間違いなく、ストレージネットワーキングに大きな圧力をかける可能性があります。

他の提案については、こちらの回答も確認してください。 ます。フラッシュストレージでの遅いチェックポイントと15秒のI / O警告

同様のトピックについては、サーバーからSANへ

SANにデータを保存する理由 ポイントは何ですか？すべてのデータベースのパフォーマンスはディスクI / Oに関連付けられており、背後のI / O用に1つのデバイスのみを持つ3つのサーバーを使用しています。それは意味がありません...そして残念ながらとても一般的です。

私は、人々が大規模なコンピューターを設計しようとするだけの、不十分に設計されたハードウェアプラットフォームに出会って一生を過ごします。ここでのすべてのCPUパワー、そこにあるすべてのディスク...できれば、リモートRAMなどはありません。そして最も悲しいのは、彼らがこの設計の効率性の欠如を、必要以上に10倍の費用がかかる巨大なサーバーで補うことです。100万ドルのラップトップよりも40万ドルの速度が遅いのを見ました。

SQLサーバーソフトウェアは非常に高度なソフトウェアであり、ハードウェア、CPUコア、CPUキャッシュ、TLB、RAM、ディスクコントローラー、ハードドライブキャッシュのあらゆるビットを活用するように設計されています...ほとんどすべてのファイルシステムロジックが含まれています。通常のコンピューターで開発され、ハイエンドシステムでベンチマークされます。そのため、SQLサーバーには独自のディスクが必要です。SANにそれらをインストールすることは、コンピューターを「エミュレート」するようなもので、パフォーマンスの最適化がすべて失われます。SANは、バックアップ、不変ファイル、およびデータを追加するだけのファイル（ログ）を保存するためのものです。

データセンター管理者は、管理できるストレージプールが1つしかないため、各サーバーのストレージを管理するよりも簡単であるため、SANにすべてを配置する傾向があります。これは「仕事をしたくない」という選択であり、非常に悪い選択です。なぜなら、彼らはパフォーマンスの問題に対処しなければならず、すべての会社がこれに苦しんでいるからです。設計されたハードウェアにソフトウェアをインストールするだけです。複雑にしないでおく。I / O帯域幅、キャッシュおよびコンテキストスイッチのオーバーヘッド、リソースのジッター（リソースが共有されている場合に発生します）に注意してください。デバイスの10分の1を同じ生出力で維持し、運用チームの頭痛の種を減らし、エンドユーザーの満足度と生産性を向上させるパフォーマンスを獲得し、会社をより良い職場にします。多くのエネルギーを節約します（地球はあなたに感謝します）。

あなたはコメントで言った、あなたはあなたのサーバーにSSDを入れることを考えている。SANと比較すると、同じドライブにデータファイルとトランザクションログファイルがある場合でも、500倍の改善が得られます。最先端のSQL Serverには、異なるハードウェアコントローラーチャネル上のデータとトランザクションログ用に高速の独立したSSDがあります（ほとんどのサーバーマザーボードには複数あります）。しかし、あなたの現在の設定と比較して、私たちはそこでSFについて話している。SSDを試してみてください。

OK、興味のある方は、

数か月前の質問で、3台のサーバーのそれぞれに直接接続されたSSDドライブをインストールし、DBデータとログファイルをSANからそれらのSSDドライブに移動するだけで問題を解決しました。

SSDドライブのインストールを決定する前に、この問題に関するすべての投稿の推奨事項を使用してこの問題を調査するために私がしたことの概要を以下に示します。

1）3つのサーバーすべてで、次のドライブのPerfMonカウンターの収集を開始しました。

Disk F:SANベースの論理ディスク、MDFデータファイルを
Disk I:含むSANベースの論理ディスク、LDFログファイルを含む
Disk T: SSDが直接接続され、tempDB専用

下の写真は、2週間の期間に収集された平均値です

Disk I: (LDF)無視することができます：ディスク私はそのような小さなIOとレイテンシは、非常に低いですしてい
ますが、その見ることができるDisk T: (TempDB)大きなIOを比較しましたDisk F: (MDF) - 0ミリ秒を、そしてそれは同時に、より良いレイテンシを持っています

明らかに、ディスクFには何か問題があります。データファイルが存在する場所では、IOが低いにもかかわらず、レイテンシと平均ディスク書き込みキューが高くなります。

2）このWebサイトからのクエリを使用して、個々のデータベースのレイテンシを確認しました

https://www.brentozar.com/blitz/slow-storage-reads-writes/

プライマリサーバー上のアクティブなデータベースには、読み取りレイテンシが150〜250ミリ秒、書き込みレイテンシが150〜450ミリ秒
というものはほとんどありませんでした。SANに何か問題がある別の兆候

3）特定のタイミングはなかった

その間に「SQL Serverで発生が発生しました...」というメッセージが
表示されたこれらのメッセージがログに記録されたときに、メンテナンスまたはディスクの重いETLが実行されていませんでした

4）Windowsイベントビューアー

「SQL Serverで発生が発生しました...」を除き、問題を示唆する他のエントリを表示しませんでした

5）上位10個のクエリのチェックを開始しました

sp_BlitzCache（cpu、readsなど）から、可能な限り最適化する
大量のデータを大量に蓄積し、ストレージに大きな影響を与えるスーパーI / Oの重いクエリはありませんが
、データベースのインデックス作成は問題ありません。

6）SANチームはありません

SANへのネットワークパスを支援するシステム管理者は1人だけです。マルチパスであり、3台のサーバーのそれぞれに2本のネットワークケーブルがあり、スイッチとSANに接続され、1ギガバイト/秒と想定されています

7）CrystalDiskMarkの結果はありませんでした

または、サーバーがセットアップされたときのその他のベンチマークテストの結果、速度がどうあるべきかがわかりません。この時点でベンチマークを実行して、現在の速度を確認することはできません。

8）問題のデータベースのチェックポイントイベントで拡張イベントセッションをセットアップする

XEセッションは、「SQL Serverで発生が発生しました...」メッセージ中に、チェックポイントが非常に遅い（最大90秒）ことを発見するのに役立ちました

9）SQL Serverエラーログ

含まれる「FlushCache」「Saturation」エントリ
これらは、特定のデータベースのチェックポイント時間がリカバリ間隔設定を超えたときに表示されるはずです

詳細は、チェックポイントがフラッシュしようとしているデータの量が少なく、完了するまでに長い時間がかかり、全体の速度が約0.25 MB /秒であることを示しました...奇妙な

10）最後に、この写真はストレージのトラブルシューティングチャートを示しています。

「ハードウェアの問題：-システム管理者/ハードウェアベンダーと協力して、SAN、古い/障害のあるドライバー、コントローラー、ファームウェアなどの設定ミスを修正する」だけのようです。

別の質問「Slow checkpoint ...」では、フラッシュストレージでの遅いチェックポイントと15秒のI / O警告 、トラブルシューティングのためにハードウェアレベルとソフトウェアレベルでチェックする必要がある項目の非常に良いリストがありました。

私たちのシステム管理者はリストからすべてのものをチェックできなかったので、この問題でいくつかのハードウェアを投げることを選択しました-それはまったく高価ではありませんでした

解決：

1 TB SSDドライブを注文し、サーバーに直接インストールしました

可用性グループがあるため、セカンダリレプリカでSANからSSDにDBデータファイルを移行してから、フェールオーバーし、以前のプライマリでファイルを移行しましたこれにより、合計ダウンタイムを最小限に抑えることができました-1分未満

現在、各サーバーにはDBデータのローカルコピーが
あり、前述のSANに対して完全/差分/ログバックアップが行われます。Windowsイベントビューアーログの「SQL Serverで発生が発生しました...」メッセージ、バックアップのパフォーマンス、整合性チェック、インデックスの再構築、クエリなどが大幅に増加しました

DBファイルをSSDに移行してから、IOレイテンシの面でどの程度パフォーマンスが向上しましたか？

影響を評価するために、移行の2週間前と移行の4週間後にパフォーマンスWindowsパフォーマンスモニターログを使用しました。

また、以下はDBレベルのレイテンシ統計の比較です（SQL Serverのキャプチャされた仮想ファイルの統計を移行前後に使用）

概要

SANから直接接続されたローカルSSDへの移行は価値がありました
それました。ストレージのレイテンシに大きな影響を与え、平均で特に90％以上改善されました（特にWRITE操作）。

ローカルSSDに移行することで、ストレージパフォーマンスの問題だけでなく、懸念していたデータの安全性も解決しました（SANに障害が発生した場合、3つのサーバーすべてが同時にデータを失います）