博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

发布订阅延迟故障排查案例:分发读进程延迟

Posted on 2013-01-09 10:16  nzperfect  阅读(1262)  评论(0编辑  收藏  举报

背景:
最近一段时间,有一个发布订阅在晚上总是报延时,由于晚上在copy备份占用带宽,而且晚上没有人使用订阅上的数据,所以也一直没有去看,最近有时间,上去看了下,发现诸多问题,服务器是12GB内存16CPU.

排查步骤及解决办法:
1.查看到当前大量的PAGEIOLATCH_SH等待信息,执行的是分发的读程进命令SQL-sp_MSget_repl_commands,怀疑IO/内存有压力,理论上分发库不大,应该可以全部缓存在内存中:


2.于是查看分发库大小,发现有22GB,再查看表msrepl_commands数据量,居然有4000W,16GB大小:

3.需要再排查一下是发布到分发分发到订阅是哪个出现了延时,结果表明是分发到订阅出现了延时(null代表在指定时间内没有反回数据,也就是数据没有传输到),采用的方法:tracer tokens

4.查看MSdistribution_history表信息,发现每5分钟记录的分发进程中,读取进程reader fetch时间都很大,都在300秒以上,初步判断为从分发到订阅这个步骤中,读出现了延时,写没有延时:

5.由于读进程要从MSrepl_commands中读取,而这个表又特别大,在读取时有PAGEIO*等待,所以怀疑跟这个表有直接关系,于是需要找到这个表为什么会这么大;

6.进一步查找表大的原因,查看分发属性,我们可以看到至少保留为0,那也就是说清除这个表的那个job出现了问题;

7.于是查看job,发现没有这个job,正常这个job名称为:Distribution clean up: distribution,同时发现也缺少job:Agent history clean up: distribution, 猜测可能是被误删除了,接下来从另外一台分发服务器上,生成这两个job的脚本,到这台分发上来执行,注意需要改servername。

8.接下来运行job:Distribution clean up: distribution(运行了很长时间),之后再查表MSrepl_commands,大小变成100+.

9.之后再观察上面1中的这些等待没有了、运行上面3已经没有延时,再查看表MSdistribution_history表信息,结果如下,可以看到reader fetch变成了0,问题解决。

10.继续运行两天,发现延时问题没有再出现。

nzperfect 2013.01.09