通常、毎週の完全バックアップは約35分で完了し、毎日の差分バックアップは約5分で完了します。火曜日以来、デイリーは完了するのにほぼ4時間かかりました。偶然にも、新しいSAN /ディスク構成を取得した直後にこれが起こり始めました。
サーバーは運用環境で実行されており、全体的な問題はなく、スムーズに実行されていることに注意してください-主にバックアップパフォーマンスに現れるIOの問題を除きます。
バックアップ中にdm_exec_requestsを見ると、バックアップは常にASYNC_IO_COMPLETIONで待機しています。ああ、ディスクの競合があります！
ただし、MDF（ログはローカルディスクに保存されます）もバックアップドライブにもアクティビティはありません（IOPS〜= 0-十分なメモリがあります）。ディスクキューの長さも〜= 0です。CPUは2〜3％程度動きますが、問題はありません。
SANはDell MD3220i、6x10k SASドライブで構成されるLUNです。サーバーは2つの物理パスを介して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時間に2、3回、バックアップ中）。そのイベントに加えて、システムイベントログには以下が記録されます。
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 / Controllerで実行されている問題のない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 and Ted Kruegersの本（29ページ）からdm_io_virtual_file_statsクエリを実行しました。上位25ファイル（各1データファイル-結果はすべてデータファイル）を見ると、読み取りは書き込みよりも悪いように見えます-書き込みはSANキャッシュに直接送られるのに対し、コールドリードはディスクをヒットする必要があるためです-ただ推測。
更新-待機統計待機統計
を収集するために3つのテストを行いました。グレンベリー/ポールランダルズスクリプトを使用して待機統計を照会します。そして確認のために-バックアップはテープではなく、iSCSI LUNで行われています。ローカルディスクに行った場合の結果は似ており、結果はNULバックアップに似ています。
クリアされた統計。10分間実行、通常の負荷：
クリアされた統計。10分間実行、通常の負荷+通常のバックアップの実行（完了しなかった）：
クリアされた統計。10分間実行、通常の負荷+ NULバックアップの実行（完了しませんでした）：
更新-WTF、Broadcom？
Mark Storey-Smithsの提案とBroadcom NICのKyle Brandtsの以前の経験に基づいて、私はいくつかの実験を行うことにしました。複数のアクティブパスがあるので、停止を引き起こすことなく、NICの構成を1つずつ比較的簡単に変更できます。
TOEとLarge Send Offloadを無効にすると、ほぼ完璧な実行が得られました。
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を実行しておらず、単純なWindows Web Server 2008 R2がCIFSを介して共有を提供していました。TOEを無効にするとすぐに、すべてがスムーズに動作するようになりました。
Broadcom NICをまったく使用できない場合、つまりBroadcom NICで再びTOEを使用しないことを確認します。