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!

（编辑：湖南网）

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