延迟是AlwaysOn最大的敌人之一

延迟是AlwaysON的最大敌人之一。对AlwaysON而言,其首要目标就尽量减少(无法避免)主副本、辅助副本的数据延迟,实现主副本、辅助副本的“数据同步”。只有主副本、辅助副本的同步延迟越小越高,只读访问的实性性才会越高,数据库的RTO(Estimating Failover Time)和RPO(Estimating Potential Data Loss)也才会越小。

但延迟可能存在于AlwaysON同步的各个环节中,因此,在分析现延迟情况时,应该首先理解AlwaysON的同步过程,然后切分到每个过程中进行监控和分析。

AlwaysON同步的6大步骤

在我的上篇文章《AlwaysON的同步原理及同步模式》中,曾介绍过AlwaysON的同步过程。归结起来,主要包括如下六个步骤:

① log flush(primary)

② log capture(primary)

③ send(primary and secondary)

④ log receive and cache(secondary)

⑤ log hardened(secondary)

⑥ redo(secondary)

前两个步骤发生在主副本,最后三个步骤发生在辅助副本,中间的第三个步骤发生主副本和辅助副本之间。

另外,如果是同步提交模式,还需要增加一个步骤:辅助副本在步骤5之后,会发送一个(日志硬化)确认信息给主副本,然后才能进入redo阶段。

监控AlwaysOn的同步过程

Log Flush(Primary)

Log Flush就是将log buffer中的日志刷入到磁盘中。在SQL Server中,log buffer的大小固定为60KB,当发生事务提交时、checkpoint、或者buffer可用空间不足时,日志就会被flush磁盘中。

AlwaysON只有待主副本的日志刷入磁盘后才能继续后面的步骤(为了保护主副本的数据一致性)。因此,log flush的越快,AlwaysON后续步骤进入的就越早,延迟就越小,反之亦然。

那么,在这个阶段中,如何监控log flush的速度和性能呢?通常,我们使用如下两个性能计数器:

  • Avg. Disk sec/Write

这是一个磁盘的性能计数器,这个指标反映的是flush期间磁盘的写操作的平均响应时间,如果10ms以内,说明磁盘性能非常好,如果在10ms到20ms,说明性能较好,如果在20ms到50ms说明性能较差,如果在50ms以上,说明性能很差。

这个指标直接反映了每秒flush的日志大小,因在不同的时段、不同的业务中日志产生的大小可能不同,因此不能提供一个标准值用来衡量flush性能的好坏,不过,当这个值很大时,说明数据库操作(增、删、改)比较频繁,需要引起注意,结合后续步骤中的其他指标一起分析。

log capture(primary)

log capture发生在log flush之后,是AlwaysON中最重要的阶段(个人认为)。在这个阶段中,主副本上会为每个辅助副本维护一个发送队列,队列的内容就是从日志缓冲或者磁盘中capture的日志,而队列的大小则反映了主副本和辅助副本数据不同步的差量。

显然,在这个阶段最可能影响AlwaysON同步性能的两个关键因素就是:capture日志的来源(是磁盘还是内存)和队列的大小。

在上述两个因素中,我需要着重解释下capture日志的来源:是磁盘还是内存?我们自导,从内存中读取数据效率要远远高于从磁盘中读取,所以在AlwaysON中,SQL Server会尽可能多将日志缓冲到内存中。但缓冲的大小是有限的,如果日志量太大、缓冲的大小不足,则不得不读取磁盘。

下面我们来熟悉下如何监控日志的来源和发送队列的大小:

监控日志的来源:

日志到底是读取自内存还是磁盘,通过如下性能计数器可窥见一斑:

  • SQL Server:Databases:Log Pool Requests/sec和SQL Server:Memory Manager:Log Pool Memory (KB)

解释:前者表示每秒中从内存中请求日志块的数量;后者表示log pool memory的大小;

说明:对于这两个值,我们希望越高越好,则说明越多的日志可以从内存中读取到。

  • SQL Server:Databases:Log Pool Disk Reads/sec和SQL Server:Databases:Log Pool Cache Misses/sec

解释:两个性能计数器其实都表示内存中找不到要读取的日志,必须从磁盘中读取;

说明:如果两个值越高,说明内存性能不足,SQL Server没法缓冲更多的日志。

监控日志发送队列:

在主副本上执行如下语句即可:

SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server, dr_state.database_id as database_id,

dr_state.log_send_queue_size, is_ag_replica_local = CASE

WHEN ar_state.is_local = 1 THEN N'LOCAL'

ELSE 'REMOTE'

END ,

ag_replica_role = CASE

WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'

ELSE ar_state.role_desc

END

FROM (( sys.availability_groups AS ag JOIN sys.availability_replicas AS ar ON ag.group_id = ar.group_id )

JOIN sys.dm_hadr_availability_replica_states AS ar_state ON ar.replica_id = ar_state.replica_id)

JOIN sys.dm_hadr_database_replica_states dr_state on

ag.group_id = dr_state.group_id and dr_state.replica_id = ar_state.replica_id;

log_send_queue_size表示主数据库中尚未发送到辅助数据库的日志记录量 (KB),也就是上文说的发送队列,如果某个辅助副本的发送队列持续增加,说明此副本与主副本同步的数据差量就越大。

在上例中,server1是主副本,server2是辅助副本。主副本的log_send_queue_size始终为null,server2的log_send_queue_size为154067KB。显然,此时server2明显落后于主副本。

send(primary and secondary)

send阶段是 AlwaysON同步过程中最简单的一个步骤(个人认为)。在这个阶段中,我们主要关注网络性能就好了,因为主副本必须借助网络才能把发送队列的日志传输到到对应的辅助副本。如果网络不好,AlwaysON就会产生延迟,更有甚者,如果是在同步提交模式下,还会导致主副本的事务迟迟不能提交。

对网络的监控主要通过如下两个性能计数器即可:

  • Network Interface:bytes sent/sec

解释:网卡每秒发送的字节数;

说明:对于这个指标我们不能孤立来看,需结合发送队列的大小,当发送队列很大,但此性能指标持续比较低时,有可能是网络有问题(当然,如果是同步模式,需要考虑辅助副本log harden的速度才能决定是否一定跟网络有关)。

  • Network Interface:output Queue Length

解释:网卡的发送队列大小;

说明:一般来说,网卡的队列大于2时,说明网络存在拥堵,可能出现了网络问题。

Log Receive and cache(sencondary)

log receive and cache发生在辅助副本上,表示辅助副本接受来自主副本发送的日志块、并缓冲起来的过程。

这个阶段其实跟网络速度和内存大小有关,两者在上文中均有介绍,这里不做过多阐述,只跟大家介绍下这个阶段中AlwaysON专有性能计数器。

解释:每秒接受的日志大小(单位为KB);

说明:接受的速度越快,说明网络性能和内存性能均越好。

Log Hardened(sencondary)

介绍log hardened时不得不谈一谈第一个步骤的log flush,两者其实是一个东西,只是表述不一样。因为它们无论是工作原理还是对事务提交的影响都非常类似,因此对log hardened的监控,直接参考步骤一就好了。

redo(secondary)

redo的对象是辅助副本中已经固化的日志(该日志可能是内存中副本,也可能来自磁盘上),是AlwaysON中“实现”数据同步的步骤,其他步骤都是为此做铺垫,即便是上个步骤的日志固化,它也只能保证主副本和辅助副本的数据一致,而真正的数据同步必须等待辅助副本的redo完成。

在这个阶段中,有两个因素决定了数据延迟的大小:redo的日志大小和redo的速度。下面我们从这两个角度来了解下redo阶段的性能监控:

监控redo日志大小

SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server, dr_state.database_id as database_id,

dr_state.redo_queue_size, is_ag_replica_local = CASE

WHEN ar_state.is_local = 1 THEN N'LOCAL'

ELSE 'REMOTE'

END ,

ag_replica_role = CASE

WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'

ELSE ar_state.role_desc

END

FROM (( sys.availability_groups AS ag JOIN sys.availability_replicas AS ar ON ag.group_id = ar.group_id )

JOIN sys.dm_hadr_availability_replica_states AS ar_state ON ar.replica_id = ar_state.replica_id)

JOIN sys.dm_hadr_database_replica_states dr_state on

ag.group_id = dr_state.group_id and dr_state.replica_id = ar_state.replica_id;

监控redo的速度

redo的速度通过如下性能计数器即可:

解释:辅助副本每秒完成redo的字节数;

说明:在分析此指标时,必须结合redo的日志大小,将两者的结果相除可得到一个大致的同步延迟时间。

结尾

我们知道AlwaysON是SQL Server 2012才开始引入的技术,目前笔者做的案例还不是很多,本文所表述的内容都是基于我有限的实践经验总结而来,如有不妥之处还请批评指正。

附上我的新浪微博二维码,希望我的分享能够为您带来一些价值。

AlwaysON同步性能监控的三板斧的更多相关文章

  1. AlwaysOn 同步时间的测试

    背景 <SQL Server 2012实施与管理实战指南>中指AlwaysON同步过程如下: 任何一个SQL Server里都有个叫Log Writer的线程,当任何一个SQL用户提交一个 ...

  2. cAdvisor0.24.1+InfluxDB0.13+Grafana4.0.2搭建Docker1.12.3 Swarm集群性能监控平台

    目录 [TOC] 1.基本概念 ​ 既然是对Docker的容器进行监控,我们就不自己单独搭建cAdvisor.InfluxDB.Grarana了,本文中这三个实例,主要以Docker容器方式运行. 本 ...

  3. AlwaysON同步的原理及可用模式

    新一代读写分离技术——AlwaysOn 早在SQL Server 2005的时候微软就已经实现了数据库的查询分离技术——发布订阅.但生产库和查询库的同步性能较差,时常出现性能问题,因此在大型生产环境中 ...

  4. NanoProfiler - 适合生产环境的性能监控类库 之 实践ELK篇

    上期回顾 上一期:NanoProfiler - 适合生产环境的性能监控类库 之 大数据篇 上次介绍了NanoProfiler的大数据分析理念,一晃已经时隔一年多了,真是罪过! 有朋友问到何时开源的问题 ...

  5. 【转载】Linux系统与性能监控

    原文地址:http://kerrigan.sinaapp.com/post-7.html Linux System and Performance Monitoring http://www.hous ...

  6. Linux性能监控

    转自:http://blog.csdn.net/chosen0ne/article/details/8200737 linux性能监控,就是要监控系统的各个子系统是否正常.linux主要的子系统包括: ...

  7. Linux系统与性能监控

    原文地址:http://kerrigan.sinaapp.com/post-7.html Linux System and Performance Monitoring http://www.hous ...

  8. AlwaysON同步过程

    <SQL Server 2012实施与管理实战指南>中指AlwaysON同步过程如下: 任何一个SQL Server里都有个叫Log Writer的线程,当任何一个SQL用户提交一个数据修 ...

  9. SQL Server AlwaysON 同步模式的疑似陷阱

    原文:SQL Server AlwaysON 同步模式的疑似陷阱 SQL Server 2012 推出的最重要的功能之一Alwayson,是一个集之前Cluster和Mirror于一体的新功能,即解决 ...

随机推荐

  1. easyui1.32 各种问题汇总

    问题一 场景:tab切换,每个tab里用div放一个dataGrid,默认display:none隐藏,当display:'block'的时候,dataGrid会显示不全,仅显示一条线. 解决方法:切 ...

  2. XproerIM V1,2,12,65376 发布。

    客户端下载:http://yunpan.cn/QTCxKvcpC4Iet  访问密码 9141 更新说明:1.增加表情功能. 更新代码截图:

  3. framebuffer应用编程实践

    framebuffer的使用主要包括4个部分: (1):首先需要打开设备文件 /dev/fb0. (2):获取设备的信息.包括可变信息和不可变信息,分别使用两个结构体来进行封装,这两个结构体在 < ...

  4. Selenium2+python自动化15-select下拉框

    前言 最近由于工作原因,更新慢了一点,今天终于抽出一点时间给大家继续更新selenium系列,学习的脚本不能停止,希望小伙伴能多多支持. 本篇以百度设置下拉选项框为案例,详细介绍select下拉框相关 ...

  5. POSIX信号处理

    信号用于通知进程发生了某件事情,可以由一个进程发给另一个进程,也可以由内核发个一个进程. 每个信号都有一个关联的行为,可以通过sigaction函数来设置一个信号的行为,有3种选择: 1.定义一个信号 ...

  6. ubuntu14安装java8

    http://ubuntuhandbook.org/index.php/2015/01/install-openjdk-8-ubuntu-14-04-12-04-lts/

  7. 获取滚动条ScrollBar宽度

    function getScrollBarWidth () { var inner = document.createElement('p'); inner.style.width = "1 ...

  8. Ceph分层存储分析

    最近弄Ceph集群考虑要不要加入分层存储 因此花了点时间研究了下 1,首先肯定要弄清Ceph分层存储的结构 ,结构图大概就是下图所示 缓存层(A cache tier)为Ceph客户端提供更好的I/O ...

  9. C#事务的使用

    1.引入相应的命名空间 using System.Transactions; 2.代码事例(using (TransactionScope ts = new TransactionScope())) ...

  10. Azure IOT (EventHub + Stream Analytics + Table Storage)的使用

    最近研究利用Azure的 Event hub ,Stream Analytics和TableStorage来实现IOT的一个方案, 利用Event hub来采集传感器设备数据值,然后输入到Stream ...