SQL Serverは、15秒以上かかるI / O要求の発生を検出しました
本番SQLサーバーでは、次の構成があります。
可用性グループに結合された3台のDell PowerEdge R630サーバーは、3台すべてが単一のDellに接続されていますSAN RAIDアレイであるストレージユニット
時々、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
sys.dm_io_virtual_file_statsから各ファイルの平均レイテンシを返すPaul S. Randalの this クエリを確認してください。私たちの場合、報告された平均レイテンシは許容範囲内でしたが、カバーの下には、平均レイテンシが200ミリ秒を超える多くのファイルがありました。 - タイミングを確認してください。パターンはありますか？夜の特定の時期により頻繁に発生しますか？その場合、その時点でメンテナンスジョブが実行されているか、またはディスクアクティビティを増加させ、IOサブシステムでボトルネックを露呈する可能性がある）スケジュールされたアクティビティがあるかどうかを確認します。
- Windowsイベントビューアでエラーを確認します。スイッチまたはSANが過負荷になっているか、アプリケーションに対して適切に設定されていない場合、このログにいくつかのメッセージが表示されることがあります。この情報をSAN管理者：私たちの場合、iSCSI接続エラーが1日中頻繁に発生し、問題を示唆していました。
- SQL Serverコードを確認します。これらのメッセージを受け取ったとき、すぐにそれがIOサブシステムの問題であると考えて、それをSAN adminに渡す必要があります。データベースを確認します。大量のデータを頻繁に処理して実行されている本当に悪いクエリがありますか？悪いインデックス付け？過度のトランザクションログ書き込み？いくつかのオープンソースクエリを使用して、データベースのヘルスチェックを取得できます。プランの外観は sp_blitzCache
- これらを無視しないでください。今日、1日に数回それらを受信している可能性があります...その後、ワークロードが増加し、それらが増加し始めるのを監視するのを忘れた数ヶ月後。これらのメッセージを大量に受信すると、SQL Serverが特定のファイルにアクセスできなくなる可能性があります。tempdbの場合、これは適切ではありません。私たちの場合、SQL Serverがシャットダウンするほどの事態になりました。
私たちの解決策は、スイッチをSANスイッチにアップグレードすることでした。そうです、これらはすべてSQL Server内でカバーするポイントです。私たちがスイッチを見つけたのは、約1500のiSCSIを受け取っていたからです。 SQL ServerのWindowsアプリケーションイベントビューアで毎日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倍のコストがかかる巨大なサーバーで補うことです。 $ 400kのインフラは$ 1kのラップトップよりも遅いことがわかりました。
SQLサーバーソフトウェアは非常に高度なソフトウェアであり、ハードウェアの任意のビット、CPUコア、CPUキャッシュ、TLB、RAM、ディスクコントローラー、ハードドライブキャッシュを利用するように設計されています...ほとんどすべてのファイルシステムロジックが含まれています。これらは通常のコンピューターで開発され、ハイエンドシステムでベンチマークされています。したがって、SQLサーバーには独自のディスクが必要です。それらをSAN=コンピュータに「エミュレート」するようなものであると、パフォーマンスの最適化がすべて失われます。SANは、バックアップ、不変ファイル、およびデータ（ログ）を追加したファイルを格納するためのものです。
データセンターの管理者は、できる限りすべてをSANに配置する傾向があります。これは、管理するストレージのプールが1つしかないため、各サーバーのストレージを管理するよりも簡単だからです。それは「自分の仕事をしたくない」という選択であり、パフォーマンスの問題に対処しなければならず、すべての会社がこれに悩まされているため、非常に悪い選択です。設計されたハードウェアにソフトウェアをインストールするだけです。複雑にしないでおく。 I/O帯域幅、キャッシュおよびコンテキストスイッチのオーバーヘッド、リソースのジッターに注意（リソースが共有されている場合に発生）。デバイスの10分の1を同じ生の出力で維持し、運用チームの頭痛の種を減らし、エンドユーザーを満足させて生産性を高めるパフォーマンスを実現し、会社をより働きやすい場所にします。多くのエネルギーを節約します（地球はあなたに感謝します）。
コメントで、SSDをサーバーに配置することを検討しています。 SANと比較すると、専用SSDを使用したセットアップは認識されません。同じドライブにデータとトランザクションログファイルがあっても、500倍の改善が得られます。最新のSQL Serverは異なるハードウェアコントローラーチャネルでデータとトランザクションログ用の高速の独立したSSDを持っています（ほとんどのサーバーマザーボードにはいくつかあります）。
OK、興味のある方は、
直接接続されたSSDドライブを3台のサーバーのそれぞれにインストールし、DBデータとログファイルをSANからこれらのSSDドライブに移動するだけで、数か月前に質問の問題を解決しました
SSDドライブのインストールを決定する前に、この問題について調査するために私が何をしたか（この質問のすべての投稿からの推奨を使用）の概要を以下に示します。
1）3つのサーバーすべてで、次のドライブのPerfMonカウンターの収集を開始しました。
_Disk F:_はSANに基づく論理ディスクで、MDFデータファイルが含まれています
_Disk I:_はSANに基づく論理ディスクで、LDFログファイルが含まれています
_Disk T:_は直接接続されたSSDで、tempDB専用です
下の画像は2週間の平均値です
Disk I: (LDF)にはこのような小さなIOがあり、レイテンシが非常に低いため、ディスクI：は無視できますDisk T: (TempDB)はDisk F: (MDF)と比較してIOが大きく、同時にレイテンシがはるかに優れていることがわかります-0 MS
明らかに、ディスクFに問題があります。データファイルが存在する場合、IOが低いにもかかわらず、待ち時間と平均ディスク書き込みキューが高くなります。
2）このWebサイトからのクエリを使用して、個々のデータベースのレイテンシを確認しました
https://www.brentozar.com/blitz/slow-storage-reads-writes/
プライマリサーバー上のアクティブデータベースがほとんどなく、読み取りレイテンシが150〜250ミリ秒、書き込みレイテンシが150〜450ミリ秒
興味深いのは、マスターデータベースファイルとmsdbデータベースファイルの読み取りレイテンシが最大90ミリ秒でした。データのサイズが小さく、低い場合IO-別の問題が発生していることを示していますさん
3）特定のタイミングはなかった
その間に「SQL Serverで発生が発生しました...」というメッセージが表示された
これらのメッセージがログに記録されたときに、メンテナンスやディスク負荷の高いETLは実行されていませんでした
4）Windowsイベントビューア
「SQL Serverで問題が発生しました...」を除き、問題を示唆する他のエントリは表示されませんでした。
5）トップ10クエリのチェックを開始
Sp_BlitzCache（cpu、readsなど）から、可能な場合は最適化
ただし、大量のデータを生成し、ストレージに大きな影響を与えるような、大量のクエリはありませんIO
データベースでのインデックス作成は問題ありませんが、私はそれを維持しています
6）SANチームはありません
機会に役立つシステム管理者は1人だけです
SAN-へのネットワークパス-マルチパスであり、3台のサーバーのそれぞれにスイッチとSANにつながる2本のネットワークケーブルがあり、1ギガバイト/秒であると想定されています
7）CrystalDiskMarkの結果はありませんでした
または、サーバーのセットアップ時の他のベンチマークテストの結果、速度がどうあるべきかがわからないため、この時点で、生産に影響を与える可能性があるため、現在の速度を確認します
8）問題のデータベースのチェックポイントイベントで拡張イベントセッションをセットアップする
XEセッションは、「SQL Serverで発生が発生しました...」メッセージ中にチェックポイントの発生が非常に遅い（最大90秒）ことを発見するのに役立ちました
9）SQL Serverエラーログ
含まれる「FlushCache」「Saturation」エントリ
これらは、特定のデータベースのチェックポイント時間が回復間隔の設定を超えると表示されるはずです
詳細は、チェックポイントがフラッシュしようとしているデータの量が少なく、完了するまでに長い時間がかかること、および全体的な速度が約0.25 MB /秒であることを示しています...奇妙です
10）最後に、この図はストレージのトラブルシューティングチャートを示しています。
「ハードウェアの問題：-システム管理者/ハードウェアベンダーと協力して、SAN、古い/障害のあるドライバー、コントローラー、ファームウェアなどの構成の誤りを修正する」
別の質問「遅いチェックポイント...」 遅いチェックポイントとフラッシュストレージでの15秒のI/O警告 ショーンは、トラブルシューティングするためにハードウェアレベルとソフトウェアレベルでチェックする必要がある項目の非常に良いリストを持っていました
私たちのシステム管理者はリストからすべてのものをチェックできなかったので、この問題でいくつかのハードウェアを投げることを選択しました-それはまったく高価ではありませんでした
解決：
1 TB SSDドライブを注文し、サーバーに直接インストールしました
可用性グループがあるので、DBデータファイルをSAN=からセカンダリレプリカのSSDに移行し、フェイルオーバーして、以前のプライマリにファイルを移行しました。これにより、合計ダウンタイムが最小限に抑えられました-1分未満
これで、各サーバーにDBデータのローカルコピーが作成され、前述のSANに対して完全/差分/ログバックアップが実行されます
Windowsイベントビューアのログに「SQL Serverで発生した...」というメッセージが表示されなくなり、バックアップ、整合性チェック、インデックスの再構築、クエリなどのパフォーマンスが大幅に向上しました
DBファイルをSSDに移行してから、IOレイテンシの点でどの程度のパフォーマンスが向上しましたか？
影響を評価するために、パフォーマンスの2週間前と4週間後のWindowsパフォーマンスモニターログを使用しました。
また、以下はDBレベルのレイテンシ統計の比較です（SQL Serverのキャプチャされた仮想ファイルの統計を移行前と移行後に使用）
概要
SANから直接接続されたローカルSSDへの移行は、それだけの価値がありました
ストレージのレイテンシに大きな影響を与え、平均で90％を大幅に上回り（特にWRITE操作）、IOで20-50秒のスパイクが発生しなくなりました。
ローカルSSDに移動することで、ストレージパフォーマンスの問題だけでなく、懸念されていたデータの安全性も解決されました（SANが失敗した場合、3つのサーバーすべてが同時にデータを失います）