请注意，该服务器正在生产中运行，并且没有任何总体问题，它运行平稳-除了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服务器上，并且发生在谷歌搜索它们似乎并不重要。
请注意，所有服务器都使用相同的NIC-具有最新驱动程序的Broadcom 5709C。服务器本身是Dell R610的服务器。
我不确定接下来要检查什么。有什么建议吗？
更新-运行perfmon
我尝试记录平均水平。执行备份时，磁盘秒/读和写性能计数器。备份开始时非常出色，然后基本上以50％的速度停止工作，缓慢地向100％爬行，但是花费的时间应该是原来的20倍。
显示两条SAN路径都在使用，然后断开。
备份在15:38:50左右启动-注意一切看起来不错，然后出现了一系列高峰。我不关心写入，只是读取似乎挂起。
注意开/关动作很少，尽管最终性能非常出色。
注意最长为12秒，尽管总体而言总体来说不错。更新-备份到NUL设备
为了隔离读取问题并简化操作，我运行了以下命令：
BACKUP DATABASE XXX TO DISK = 'NUL'
结果完全相同-从突发读取开始，然后停顿，不时恢复操作：
更新-IO档
按照肖恩的建议，我从乔纳森·凯海耶斯（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!
，启用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了。就是那个。
#1 楼
请注意，所有服务器都使用相同的NIC-具有最新驱动程序的Broadcom 5709C。服务器本身是Dell R610的服务器。
凯尔·布兰特（Kyle Brandt）对Broadcom网卡有自己的看法，这与我自己的（重复的）经验相呼应。
Broadcom，Die Mutha
我的问题一直与TCP卸载功能有关，在99％的情况下，禁用或切换到其他网卡已解决了该症状。一个（如您的情况）使用Dell服务器的客户端，总是订购单独的Intel NIC并在构建时禁用板载Broadcom卡。
如该MSDN博客文章中所述，我将从使用以下操作系统禁用操作系统开始：
netsh int ip set chimney DISABLED
IIRC，可能需要禁用在某些情况下，卡驱动程序级别的功能肯定不会受到损害。
#2 楼
并不是说我是SAN /磁盘专家（这里的人对我了解更多）...我只分享我所做的一些工作，并且大多读到:)Jonathan Kehayias泰德·克鲁格（Ted Krueger）写了一本书《对SQL Server进行故障排除》，其中包含有关磁盘性能的一些很好的信息。您可以从这里免费获取PDF。 （我也可以在我的办公桌上购买印刷版。）无论如何，他们都有一个很好的查询，该查询可用于检查sys.dm_io_virtual_file_stats并检查数据文件的平均延迟。您可能会发现RAID10不是存放数据文件的理想配置。
评论
即使RAID10并不是最佳配置，我也看不出这是问题所在。正常使用期间，磁盘上的活动几乎为零，并且错误的RAID级别无法解决此类缓慢的IO请求。正如SQLIO所示，我能够以2-4k IOPS的速度进行200MB / s +的写入和100MB / s +的读取，因此具有足够的容量。我已使用dm_io_virtual_file_stats查询结果的结果更新了该帖子。请注意，如果直接打开图像，则图像较大。
–马克·拉斯穆森（Mark S. Rasmussen）
2012年1月19日在17:11
评论
数据文件位于专用的6磁盘RAID10 LUN上。备份文件存储在单独的LUN中。到目前为止，我没有看到备份驱动器/文件受到影响的迹象，它似乎只是数据驱动器。所有LUN均启用了写缓存，这是全面的默认设置。我不认为它与缓存相关，因为即使NUL备份也存在问题-从而消除了写入问题。对于读取，每个控制器都有2GB的读取缓存，再加上主机上的内存（如果有足够的内存，则它具有无限PLE）。