web-dev-qa-db-ja.com

SSD上のSQL Server tempdbにIO

Tempdbファイルを新しいSSDに分離したところ、次のことがわかりました。

ファイル[T：\ tempdb\tempdb4.ndf]で完了するのに15秒以上かかるI/O要求の5348回の発生。

このエラーは複数回発生しています。 tempdbが元のRAID 5ホームに戻ったときにエラーは発生しませんでした。 SQLIOのチュートリアルに従って、8 KBのランダムな読み取り/書き込みを実行すると、SSDは以前のRAID 5ディスクよりもはるかに高速になるはずです。では、なぜこれらのエラーが発生するのでしょうか。

また、すべてが順調ではないことをさらに証明するために、夜間に実行するバッチファイル（これらのエラーが発生したとき）は7時間かかります。古いディスクで6.25時間かかりました。

ディスクは直接接続されたアレイに配置されます。データ用のRAID5、ログ用のRAID 10、およびSSDに使用したスペアスロット。 RAID 5とSSDは、64kbのブロックサイズ用にフォーマットされています。ログのブロックサイズが4KBに誤って設定されています（わかっています。機会があれば修正します）。

SQLIOの結果は次のとおりです。

Tドライブ（ssd）
Ios = 8KBランダム書き込み、IOs/sec = 31847.48、MBs/sec = 248.8
Ios = 8KBランダム読み取り、IOs /秒= 76391.66、MBs /秒= 596.8

Sドライブ（RAID 5）
Ios = 8KBランダム書き込み、IOs/sec = 2601.3、MBs/sec = 20.32
Ios = 8KBランダム読み取り、IOs/sec = 3138.45、MBs/sec = 24.51

64Kの順次読み取り/書き込みの場合、それらはほぼ同じでした。

Tempdbは4つの1.5Gbファイルに分割されます（これは移動の前後で同じです）。

SQL Server 2012はSP3にパッチされています。

SQL Serverから報告されるこれらのI/Oエラーの原因は何ですか？

アレイまたはHBAドライバーの問題ですか？直接接続されたアレイのスペアスロットに追加された単一のディスクは、キャッシュに関して注意深い構成が必要ですか？

sql-serversql-server-2012tempdb
8
G Devine

Crystal Disk Markを使用して新しいT：\ドライブをテストすることを強くお勧めします。ブレントオザーのガイドはこちらからご覧ください。

CrystalDiskMarkを使用してストレージをテストする方法

T：\ドライブからの結果を

  • 古いRAID 5ディスク（tempdbが使用されていた場所）
  • あなたのマシン

SSDが他の2つのデバイスよりも遅く、セットアップで他に何も変更されていない*場合は、ディスク自体、使用されているドライバー、またはこのディスクが配置されているアレイのコントローラーに問題がある可能性があります。等.

* tempdbを移動してから変更された可能性があるもの：

  • データベースのtempdbファイルの数が増減した（誰かが「とにかくtempdbを移動するにはデータベースを再起動する必要があるため、そうではない」と言った）
  • メンテナンスタスクは、夜遅くなる今のジョブ（特に、インデックスの再構築やcheckdbなど、tempdbにハードヒットする可能性があるジョブ）に合わせて再スケジュールされました。
  • tempdbを移動するためのメンテナンスウィンドウは、一時テーブルをより頻繁に使用したり、クエリに悪影響を及ぼすなどの新しいコード（おそらく毎晩のジョブ）を展開するためにも使用されました。

次のステップ

（あなたが共有したベンチマークによると）ディスクはかなり高速であるように思われるので、毎晩のバッチジョブの前後に sys.dm_io_virtual_file_stats の内容をログに記録することをお勧めします言及した。これにより、そのプロセス中にtempdbで発生しているI/Oの量がわかります。ディスクが処理できる以上のI/Oが実際にある可能性があるため、これは重要です。だからここにあなたがすることです：

  1. このクエリは、毎晩のバッチジョブの実行がスケジュールされる直前に実行します。

    select * 
from sys.dm_io_virtual_file_stats((select DB_ID('tempdb')), default);

  2. 結果をどこかに保存します（Excelのようなもの-おそらくtempdbにはありません：P）

  3. 7時間待ちます（ジョブが完了するまで）
  4. 同じクエリを実行して結果を保存する
  5. 質問を編集して結果を含めます

次に、2つのスナップショットの違いを取得して、ジョブ中に読み書きされたバイト数を判断できます。これらの数値を使用して、その期間の全体的なレイテンシを計算することもできます。

注：より詳細なアプローチは、クエリの結果を5分ごとに（または必要に応じてそれより少なく）テーブルに記録することです

7
Josh Darnell

この問題は解決されたようです。

SAN=チームで問題を提起したところ、アレイでSSDディスクのキャッシュが無効になっていることが確認されました。キャッシュが有効になると、SQL Serverエラーログからエラーが消えました。

RAIDアレイにこれらの追加設定が必要であることを知らなかったことを認めなければなりません。私はそれが何の介入もなく機能することを期待していました。

彼らはまた、Smart Arrayソフトウェアを更新し、最新のパッチを適用しました。いずれにせよ、彼らはDBAが提案する必要はなかったと思います。

私と一緒にこの問題を検討するために時間を割いてくださった皆さんに感謝します。

ガレット

3
G Devine