通常，我们每周的完整备份大约需要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的冗余连接-共有4条路径，其中两条在任何时间都处于活动状态。我可以通过任务管理器验证两个连接均处于活动状态-完美地平均分配负载。两种连接都运行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 / Controller上运行的非问题CIFS服务器上，从我的Google搜索中看，它们似乎不是关键。
请注意，所有服务器都使用相同的NIC-具有最新驱动程序的Broadcom 5709C。服务器本身是Dell R610的服务器。
我不确定接下来要检查什么。有什么建议么？
更新-运行性能监视器
我尝试记录平均水平。执行备份时，磁盘秒/读和写性能计数器。备份开始时非常出色，然后基本上以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，Broadcom？
根据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后，一切都变得像魅力。猜猜我以后不会再订购Broadcom NIC了。
更新-CIFS服务器
宕机了今天，功能相同的CIFS服务器开始显示IO请求挂起。该服务器未运行SQL Server，仅运行普通的Windows Web Server 2008 R2通过CIFS提供共享。当我也禁用TOE时，一切都恢复了平稳运行。
只是确认我将永远不会再在Broadcom NIC上使用TOE，如果我无法完全避免使用Broadcom NIC，那就是。