如何精确监控DB响应延时

原创
08/17 00:00
阅读数 29

本文首发于 「老叶茶馆」 微信公众号。

作者:任坤,现居珠海,先后担任专职 Oracle 和 MySQL DBA,现在主要负责 MySQL、MongoDB 和 Redis 维护工作

原创内容未经授权不得随意使用,转载请联系小编并注明来源。

1、背景

日常工作中遇到被问的最多的就是“现在应用有点慢,帮忙看看db是不是有问题”,第一反应是要去看一下监控告警。

问题是线上的监控指标很多,OS的包括cpu内存IO网络,DB主要有TPS/QPS活跃连接数锁等待(细分的更多),就算把所有监控信息都放到grafana单个页面展示,挨个查看也要耗费一点时间。

更关键的是,即便上述指标都正常,也不等同于DB无恙,即这些指标只能算是DB健康的必要条件,而不是充分条件。在某些场景下,即便这些指标都很平稳,开发可能依然会不断的质疑你,这时要如何快速自证清白?

首先来梳理一下DB响应流程:
从应用程序的角度观察,DB响应速度 = 网络延时 + 处理延时,其中处理延时的时间从请求抵达DB服务器开始,到服务器将响应结果发出结束。

DB服务器任何一个环节出现问题,都会增大处理延时,进而触发上述场景。

为此,我们只需要监控每个db请求【进入db服务器,db响应结束】这段时间的耗时,便可计算出每个db请求的处理延时,进而判定db服务器是否健康。 tcprstat是专门为统计处理延时而生的工具。

2、原理

官档原文:原文

Here “response time” means, for a given TCP connection, the time elapsed from the last inbound packet until the first outbound packet.

通过(src_ip, src_port, dst_ip, dst_port)四元组可以唯一标识1个tcp连接,对于每个连接,计算其最后1个入包和第1个出包的时间差,以此得出1个请求的处理延时,然后将所有连接的请求处理延时聚集统计并输出。

这里有个前提,服务端IO模型必须是同步阻塞模式,即当前request的响应完成后,才能接受下一个request,好在目前的主流DB都符合这个要求。

tcprstat在启动时会创建一个hash表,默认2053个bucket,每个bucket挂载一条单向链表,当出现hash冲突时,遍历该bucket下的链表直至找到匹配的item。

借助libpcap捕获数据包,首先将其还原成ip包(struct ip),根据(ip->ip_p == IPPROTO_TCP)过滤掉非tcp包, 并且去除只包含控制信息的tcp包。tcprstat会记录每个符合条件数据包的时间戳tv,以及对应的四元组(src_ip, src_port, dst_ip, dst_port),对四元组取模,以此在hash表中定位查找。

对应的数据结构很简单:

struct session {
uint32_t laddr, raddr;
uint16_t lport, rport;
struct timeval tv;
struct session *next;
}
  • 如果该包是入包,将其插入到hash表,若对应的item已经存在,覆盖其已有tv值。
  • 如果该包是出包,根据其四元组从hash表取出对应item并将其从hash表移除,将两个包的tv相减便得出该请求的处理延时。

tcprstat将每个请求的处理延时保存到1个长整型数组中,每次输出都要对这个指针数组进行遍历,比如计算avg。

for (i = 0; i < n; i++)
    avg += stats[i];
avg /= n;

而计算99_avg时,则先对指针数组调用qsort()进行升序排列,并只计算前99%的元素,排除最高的1%

n = ( n * percentile ) / 100
for (i = 0; i < n; i++)
    avg += stats[i];
avg /= n;

计算min和max同理。

3、安装

安装很简单,直接将二进制文件下载就会执行

wget http://github.com/downloads/Lowercases/tcprstat/tcprstat-static.v0.3.1.x86_64
cp -a tcprstat-static.v0.3.1.x86_64 /usr/bin/tcprstat
chmod +x /usr/bin/tcprstat

该工具默认直接查询机器的网络接口,在bonding模式的网卡下会报错,可改用ip列表。

[root@ ~]# tcprstat -p 3306
pcap: SIOCGIFFLAGS: bonding_masters: No such device

[root@ ~]# tcprstat -p 3306 -n 0 -t 1 -l `/sbin/ip a| grep inet | egrep 'eth|lo' | awk '{print $2}' | cut -d'/' -f1 | xargs echo | sed -e 's/ /,/g'`  
timestamp       count   max     min     avg     med     stddev  95_max  95_avg  95_std  99_max  99_avg  99_std
1488445537      0       0       0       0       0       0       0       0       0       0       0       0
1488445538      1       663     663     663     663     0       0       0       0       0       0       0
1488445539      0       0       0       0       0       0       0       0       0       0       0       0
1488445540      2       44      27      35      44      10      27      27      0       27      27      0
1488445541    3       604     46      264     142     243     142     94      48      142     94      48

以图形化的方式展现,当应用出现性能问题时可快速排查是否由DB引发,只有avg/99_avg出现剧烈波动时,才能证明db服务器响应有问题。

4、总结

可以做如下结论:tcprstat.avg/99_avg平稳是db健康的充分必要条件。虽然作者原本是为了监控mysql开发的此工具,但是对于mongoredis同样适用,只需要修改监控端口即可。

全文完。

Enjoy MySQL :)


文章推荐:



扫码加入GreatSQL/MGR交流QQ群



点击文末“阅读原文”直达老叶专栏

本文分享自微信公众号 - 老叶茶馆(iMySQL_WX)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部