超過 15 秒的 I/O 請求

通常我們每週的完整備份在大約 35 分鐘內完成，每日差異備份在大約 5 分鐘內完成。自周二以來，日報已經花費了將近 4 個小時來完成，遠遠超過了應有的時間。巧合的是，這在我們獲得新的 SAN/磁碟配置後就開始發生了。

請注意，伺服器正在生產中執行，我們沒有整體問題，它執行平穩 - 除了主要表現在備份性能中的 IO 問題。

在備份期間查看 dm_exec_requests，備份一直在等待 ASYNC_IO_COMPLETION。啊哈，所以我們有磁碟爭用！

但是，MDF（日誌儲存在本地磁碟上）和備份驅動器都沒有任何活動（IOPS ~= 0 - 我們有足夠的記憶體）。磁碟隊列長度 ~= 0 也是。CPU 徘徊在 2-3% 左右，也沒有問題。

SAN 是 Dell MD3220i，LUN 由 6x10k SAS 驅動器組成。伺服器通過兩條物理路徑連接到 SAN，每條路徑都通過一個單獨的交換機，並與 SAN 有冗餘連接——總共有四個路徑，其中兩個在任何時候都處於活動狀態。我可以通過任務管理器驗證兩個連接都處於活動狀態 - 完全均勻地分配負載。兩個連接都執行 1G 全雙工。

我們曾經使用巨型幀，但我已禁用它們以排除這裡的任何問題 - 沒有變化。我們有另一台伺服器（相同的 OS+config，2008 R2）連接到其他 LUN，它沒有顯示任何問題。然而，它沒有執行 SQL Server，而只是在它們之上共享 CIFS。但是，它的 LUN 首選路徑之一與麻煩的 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

我意識到這些無論如何都不是詳盡的測試，但它們確實讓我知道這並不是完全的垃圾。請注意，較高的寫入性能是由兩個活動的 MPIO 路徑引起的，而讀取將只使用其中一個。

檢查應用程序事件日誌會發現這些分散在各處的事件：

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

它們不是恆定的，但它們確實會定期發生（每小時幾次，在備份期間更多）。除了該事件，系統事件日誌將發布這些：

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 伺服器上，從我的Google搜尋來看，它們似乎不是關鍵的。

請注意，所有伺服器都使用相同的 NIC - 帶有最新驅動程序的 Broadcom 5709C。伺服器本身是戴爾 R610 的。

我不確定接下來要檢查什麼。有什麼建議？

更新 - 執行 perfmon

我嘗試記錄平均。執行備份時的磁碟秒/讀寫性能計數器。備份開始時非常火爆，然後基本上在 50% 處停止，緩慢地爬向 100%，但花費了應有的 20 倍時間。

顯示兩個 SAN 路徑都在使用，然後退出。

備份在 15:38:50 左右開始 - 注意一切看起來都不錯，然後出現了一系列峰值。我不關心寫入，只有讀取似乎掛起。

請注意開/關動作很少，儘管最後表現出色。

請注意最長 12 秒，但總體而言平均不錯。

更新 - 備份到 NUL 設備

為了隔離讀取問題並簡化操作，我執行了以下命令：

BACKUP DATABASE XXX TO DISK = 'NUL'

結果完全相同 - 從突發讀取開始，然後停止，不時恢復操作：

更新 - IO 停止

我按照 Shawn 的建議執行了 Jonathan Kehayias 和 Ted Kruegers 的書（第 29 頁）中的 dm_io_virtual_file_stats 查詢。查看前 25 個文件（每個文件一個數據文件 - 所有結果都是數據文件），看起來讀取比寫入更糟糕 - 可能是因為寫入直接進入 SAN 記憶體，而冷讀取需要命中磁碟 - 只是猜測.

更新 - 等待統計

我做了三個測試來收集一些等待統計。使用 Glenn Berry/Paul Randals腳本查詢等待統計資訊。只是為了確認 - 備份不是針對磁帶，而是針對 iSCSI LUN。如果對本地磁碟執行結果類似，結果類似於 NUL 備份。

清除統計。跑了10分鐘，正常負載：

清除統計。執行 10 分鐘，正常負載 + 正常備份執行（未完成）：

清除統計。跑了 10 分鐘，正常負載 + NUL 備份執行（未完成）：

更新 - Wtf，博通？

基於 Mark Storey-Smiths 的建議和 Kyle Brandts 以前使用 Broadcom NIC 的經驗，我決定做一些實驗。由於我們有多個活動路徑，我可以相對輕鬆地一一更改 NIC 的配置，而不會導致任何中斷。

禁用 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 被禁用，一切都像魅力一樣運作。我猜我以後不會再訂購博通網卡了。

更新 - CIFS 伺服器宕機

今天，相同且功能正常的 CIFS 伺服器開始顯示 IO 請求掛起。該伺服器沒有執行 SQL Server，只是普通的 Windows Web Server 2008 R2 通過 CIFS 服務共享。一旦我也禁用了 TOE，一切都恢復了平穩執行。

只是確認我再也不會在 Broadcom NIC 上使用 TOE，如果我根本無法避免 Broadcom NIC，那就是。

請注意，所有伺服器都使用相同的 NIC - 帶有最新驅動程序的 Broadcom 5709C。伺服器本身是戴爾 R610 的。

Kyle Brandt 對 Broadcom 網卡的看法與我自己（重複）的經歷相呼應。

博通，死穆薩

我的問題一直與TCP 解除安裝功能有關，在 99% 的情況下禁用或切換到另一個網卡已經解決了這些症狀。一個客戶端（如您的情況）使用戴爾伺服器，始終訂購單獨的英特爾 NIC，並在建構時禁用板載 Broadcom 卡。

如此MSDN 部落格文章中所述，我將從在作業系統中禁用：

netsh int ip set chimney DISABLED

IIRC 在某些情況下可能需要在卡驅動程序級別禁用這些功能，這樣做肯定不會有什麼壞處。

引用自：https://dba.stackexchange.com/questions/10950