sql-server-2008-r2 – I / O请求超过15秒

通常我们的每周完整备份在大约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配置,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.服务器本身就是戴尔R610.

我不确定接下来要检查什么.有什么建议？

更新 – 运行perfmon
我试着录制Avg. Disk sec / Read&执行备份时写入perf计数器.备份开始惨烈,然后基本停止在50％死亡,慢慢爬向100％,但它应该花费20倍的时间.

显示正在使用的两个SAN路径,然后下降.

备份在15:38:50左右开始 – 注意看起来一切都很好,然后有一系列的峰值.我并不关心这些写入,只有读取似乎挂起.

注意很少的动作开/关,尽管在最后的表现非常棒.

注意最大12秒,虽然平均总体上是好的.

更新 – 备份到NUL设备
为了隔离读取问题并简化操作,我运行了以下内容：

BACKUP DATABASE XXX TO DISK = 'NUL'

结果完全相同 – 从爆发读取开始然后停止,不时恢复操作：

更新 – IO停止
我按照肖恩的建议,从Jonathan Kehayias和Ted Kruegers book(第29页)运行了dm_io_virtual_file_stats查询.查看前25个文件(每个文件一个 – 所有结果都是数据文件),看起来读取比写入更糟糕 – 可能是因为写入直接进入SAN缓存而冷读取需要访问磁盘 – 只是猜测.

更新 – 等待统计数据
我做了三次测试来收集一些等待统计数据.使用Glenn Berry / Paul Randals script查询等待统计数据.只是为了确认 – 备份不是对磁带进行的,而是对iSCSI LUN进行的.如果对本地磁盘执行结果,则结果类似,结果类似于NUL备份.

清除统计数据.跑了10分钟,正常负荷：

清除统计数据.跑了10分钟,正常负载正常备份运行(没有完成)：

清除统计数据.跑了10分钟,正常加载NUL备份运行(没有完成)：

更新 – Wtf,Broadcom？
根据Mark Storey-Smiths的建议和Kyle Brandts之前使用Broadcom NIC的经验,我决定做一些实验.由于我们有多个活动路径,因此我可以相对轻松地逐个更改NIC的配置,而不会导致任何中断.

禁用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!

（编辑：青岛站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!