15秒以上かかるI / Oリクエスト
通常、毎週の完全バックアップは約35分で完了し、毎日の差分バックアップは約5分で完了します。火曜日から、毎日の作業が完了するまでに約4時間かかりました。偶然にも、これは新しいSAN /ディスク構成を取得した直後に発生し始めました。
サーバーは運用環境で稼働しており、全体的な問題はなく、スムーズに稼働しています。ただし、IO問題は主にバックアップパフォーマンスで明らかになります）。
バックアップ中にdm_exec_requestsを確認すると、バックアップは常にASYNC_IO_COMPLETIONで待機しています。ああ、ディスク競合が発生しました！
ただし、MDF（ログはローカルディスクに保存されます）にもバックアップドライブにもアクティビティがありません（IOPS〜= 0-十分なメモリがあります）。ディスクキューの長さ〜= 0も同様です。 CPUは2〜3％程度動きますが、問題もありません。
SANはDell MD3220i、6x10kで構成されるLUN SASドライブ。サーバーはSAN SAN-合計4つのパス、2つはいつでもアクティブです。両方の接続がアクティブであることを確認できます。タスクマネージャ-負荷を完全に均等に分割します両方の接続で1G全二重が実行されています。
以前はジャンボフレームを使用していましたが、ここでは問題を除外するためにそれらを無効にしました-変更なし。他のLUNに接続されている別のサーバー（同じOS + config、2008 R2）があり、問題はありません。ただし、SQL Serverを実行しておらず、CIFSを共有しているだけです。ただし、そのLUN優先パスの1つは、問題のあるLUNと同じSANコントローラー上にあります。そのため、これも除外しました。
いくつかのSQLIOテスト（10Gテストファイル）を実行すると、問題にもかかわらず、IOはまともです。
sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec: 3582.20
MBs/sec: 27.98
Min_Latency(ms): 0
Avg_Latency(ms): 3
Max_Latency(ms): 98
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 45 9 5 4 4 4 4 4 4 3 2 2 1 1 1 1 1 1 1 0 0 0 0 0 2
sqlio -kW -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec: 4742.16
MBs/sec: 37.04
Min_Latency(ms): 0
Avg_Latency(ms): 2
Max_Latency(ms): 880
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 46 33 2 2 2 2 2 2 2 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 1
sqlio -kR -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec: 1824.60
MBs/sec: 114.03
Min_Latency(ms): 0
Avg_Latency(ms): 8
Max_Latency(ms): 421
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 1 3 14 4 14 43 4 2 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 6
sqlio -kW -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec: 3238.88
MBs/sec: 202.43
Min_Latency(ms): 1
Avg_Latency(ms): 4
Max_Latency(ms): 62
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 0 0 0 9 51 31 6 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
これらは決して完全なテストではないことを理解していますが、完全なゴミではないことを知って安心できます。 2つのアクティブなMPIOパスが原因で書き込みパフォーマンスが向上するのに対し、読み取りではそのうちの1つのみが使用されることに注意してください。
アプリケーションイベントログを確認すると、次のようなイベントが散在しています。
SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [J:\XXX.mdf] in database [XXX] (150). The OS file handle is 0x0000000000003294. The offset of the latest long I/O is: 0x00000033da0000
これらは一定ではありませんが、定期的に発生します（1時間に数回、バックアップ中はさらに多く）。そのイベントに加えて、システムイベントログはこれらを投稿します。
Initiator sent a task management command to reset the target. The target name is given in the dump data.
Target did not respond in time for a SCSI request. The CDB is given in the dump data.
これらは、同じSAN /コントローラー上で実行されている問題のないCIFSサーバーでも発生し、私のグーグルから、それらは重要ではないようです。
すべてのサーバーが同じNIC-最新のドライバーを備えたBroadcom 5709Cを使用することに注意してください。サーバー自体はDell R610です。
次に何を確認すればよいかわかりません。助言がありますか？
更新-実行中のperfmon
平均を記録してみました。バックアップ実行中のディスク秒/読み取りおよび書き込みパフォーマンスカウンター。バックアップは非常に最初から始まり、基本的に50％で停止し、100％までゆっくりとクロールしますが、本来の時間の20倍の時間がかかります。
両方のSAN使用中のパスを示し、その後ドロップオフします。
15:38:50頃にバックアップが開始されました-すべてが正常に見えることに注意してください。その後、一連のピークがあります。書き込みは関係ありません。読み取りのみがハングしているようです。
アクションのオン/オフはほとんどありませんが、最後のパフォーマンスは非常に高いことに注意してください。
最大は12秒ですが、平均は全体的に良好です。
更新-NULデバイスへのバックアップ
読み取りの問題を分離し、物事を簡素化するために、以下を実行しました。
BACKUP DATABASE XXX TO DISK = 'NUL'
結果はまったく同じでした-バースト読み取りで始まり、その後停止して、時々操作を再開します。
更新-IOストール
Shawnの推奨に従って、Jonathan KehayiasとTed Kruegers book （29ページ）からdm_io_virtual_file_statsクエリを実行しました。上位25ファイル（各データファイル1つ-すべての結果がデータファイル）を見ると、読み取りは書き込みよりも悪いように見えます。おそらく書き込みがSANキャッシュに直接アクセスするのに対し、コールド読み取りにディスクをヒットする必要があります-推測ですが。
更新-待機統計
いくつかの待機統計を収集するために3つのテストを行いました。待機統計は、Glenn Berry/Paul Randals script を使用して照会されます。そして確認のために-バックアップはテープではなく、iSCSI LUNに対して行われています。ローカルディスクに対して行った場合の結果も同様で、NULバックアップと同様の結果になります。
統計をクリアしました。 10分間実行、通常の負荷： 
統計をクリアしました。 10分間実行、通常の負荷+通常のバックアップの実行（完了していません）： 
統計をクリアしました。 10分間実行、通常の負荷+ NULバックアップの実行（完了していません）： 
更新-Wtf、Broadcom？
Mark Storey-Smithsの提案とBroadcom NICでのカイルブランツのこれまでの経験に基づいて、実験を行うことにしました。複数のアクティブパスがあるため、停止を発生させることなく、NICの構成を1つずつ比較的簡単に変更できました。
TOEとラージセンドオフロードを無効にすると、ほぼ完璧な実行になります。 
Processed 1064672 pages for database 'XXX', file 'XXX' on file 1.
Processed 21 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064693 pages in 58.533 seconds (142.106 MB/sec).
では、TOEとLSOのどちらが原因なのでしょうか。 TOEが有効、LSOが無効： 
Didn't finish the backup as it took forever - just as the original problem!
TOE無効、LSO有効-見栄えが良い： 
Processed 1064680 pages for database 'XXX', file 'XXX' on file 1.
Processed 29 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064709 pages in 59.073 seconds (140.809 MB/sec).
また、コントロールとして、問題がなくなったことを確認するためにTOEとLSOの両方を無効にしました。 
Processed 1064720 pages for database 'XXX', file 'XXX' on file 1.
Processed 13 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064733 pages in 60.675 seconds (137.094 MB/sec).
結論として、有効なBroadcom NICが有効であるようですTCPオフロードエンジンが問題を引き起こしました。TOEが無効になるとすぐに、すべてが魅力的に機能しました。今後はBroadcom NICを注文しません。 。
更新-CIFSサーバーがダウンします
今日、機能している同一のCIFSサーバーがIO要求のハングを示しています。このサーバーはSQL Serverを実行しておらず、CIFSを介して共有を提供する単純なWindows Web Server 2008 R2のみでした。すぐに私もTOEを無効にしたので、すべてがスムーズに動作するようになりました。
Broadcom NICでTOEを再び使用しないことを確認します。BroadcomNICをまったく回避できない場合はそうです。
すべてのサーバーが同じNIC-最新のドライバーを備えたBroadcom 5709Cを使用することに注意してください。サーバー自体はDell R610です。
カイル・ブラントは、自分の（繰り返しの）経験を反映するBroadcomネットワークカードについて意見を持っています。
私の問題は常に TCPオフロード 機能に関連しており、99％のケースで、他のネットワークカードを無効にするか切り替えることで症状が解決しました。 （お客様の場合と同様に）1台のクライアントがDellサーバーを使用し、常に個別のIntel NICを注文し、ビルド時にオンボードBroadcomカードを無効にします。
この MSDNブログの投稿 で説明されているように、OSで無効にすることから始めます。
netsh int ip set chimney DISABLED
IIRC場合によっては、カードドライバーレベルで機能を無効にする必要がありますが、無効にしても問題はありません。
私はSAN /ディスクの専門家ではありません（ここには私よりも多くのことを知っている人がいます）...私は少しだけやったことを共有し、ほとんどを読みました:)
Jonathan KehayiasとTed Kruegerは、ディスクパフォーマンスに関する優れた情報が記載された本「Troubleshooting SQL Server」を執筆しました。 PDFは こちら から無料で入手できます（この印刷版も自分のデスク用に購入するかもしれません）。
とにかく、それらにはsys.dm_io_virtual_file_statsをチェックし、データファイルの平均待機時間をチェックするために使用できる優れたクエリがあります。 RAID10は、データファイルを配置するための理想的な構成ではない場合があります。