如何精确监控DB响应延时

冷不防 2022-09-05 04:11 118阅读 0赞

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

作者：任坤，现居珠海，先后担任专职 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开发的此工具，但是对于`mongo`、`redis`同样适用，只需要修改监控端口即可。

全文完。

Enjoy MySQL :)

--------------------

**文章推荐：**

*  [MGR最佳实践(MGR Best Practice)][MGR_MGR Best Practice]
 *  [万里数据库MGR Bug修复之路][MGR Bug]
 *  [在Docker中部署GreatSQL并构建MGR集群][Docker_GreatSQL_MGR]
 *  [将GreatSQL添加到系统systemd服务][GreatSQL_systemd]
 *  [金融应用场景下跨数据中心的MGR架构方案][MGR]  
    
 *  [InnoDB Cluster+GreatSQL快速部署MGR集群，并实现读写分离和故障自动转移][InnoDB Cluster_GreatSQL_MGR]
 *  [利用GreatSQL部署MGR集群，并完成添加新节点 、滚动升级、切主][GreatSQL_MGR_]
 *  [《叶问》33期，MGR最佳配置参考，PFS里的监测指标要全开吗，mysqld进程占用内存过高怎么排查][33_MGR_PFS_mysqld]

--------------------

扫码加入GreatSQL/MGR交流**QQ群**

![00f9569ea441d73cc5ba8774779675e6.png][]

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

[MGR_MGR Best Practice]: http://mp.weixin.qq.com/s?__biz=MzkzMTIzMDgwMg%3D%3D&chksm=c26f6633f518ef25f19309e4b01ce5d4527d945a2a030b66a9d9bbaa598cb668eca30cb91a0f&idx=1&mid=2247484174&scene=21&sn=4f795e889e3778876b09143c4ffdc770#wechat_redirect
[MGR Bug]: http://mp.weixin.qq.com/s?__biz=MzkzMTIzMDgwMg%3D%3D&chksm=c26f64abf518edbdb278f1c21e98e39dc73b78397d01c2d583450a1da6d72a4ff32a0ec6db9c&idx=1&mid=2247483798&scene=21&sn=21fc1b1797074e002e1c684263b731e8#wechat_redirect
[Docker_GreatSQL_MGR]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b40488a4cc95e2f4a7750a3cad05fd70d3b9b5f366ded103e66e16f2cdda6f67fa231803c&idx=1&mid=2653936162&scene=21&sn=fa76aa58c0262d6a4e43c675f305db6d#wechat_redirect
[GreatSQL_systemd]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b43ea8a4ccafc0edffe28125815e5a490370463d7f7c00436f5d58b47df58affd0afe263d&idx=1&mid=2653936000&scene=21&sn=d21f6f3a89e03c08663df5b34f6b09f8#wechat_redirect
[MGR]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b43108a4cca06841d2adf3a63dfe6af99df09b09164e8676d99cb08fc5e569bfc543a0ccf&idx=1&mid=2653935994&scene=21&sn=91c596c81944aabd396d33f4924aac26#wechat_redirect
[InnoDB Cluster_GreatSQL_MGR]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b43308a4cca26c2db9912a9ce5e2d73df1a10e7415f83538742b92e5475a0b11b88e39f4c&idx=1&mid=2653935962&scene=21&sn=38f2acfb147f16ae8daaa6a48a3102ae#wechat_redirect
[GreatSQL_MGR_]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b43258a4cca336b0260c6b9cfc363f10596c775bdd0408d89dca855f3c7949911aa50ec8f&idx=1&mid=2653935951&scene=21&sn=ec8794371cd6f7677a5355b7e7ac39ea#wechat_redirect
[33_MGR_PFS_mysqld]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b436b8a4cca7ddf138db1d2342aa19f0452bff97beb2f5015cf0eb377a7d2a6899d1c3c05&idx=1&mid=2653935873&scene=21&sn=7511853d63145b7d72ae533586b6ad81#wechat_redirect
[00f9569ea441d73cc5ba8774779675e6.png]: /images/20220829/8590bd6517d24ad09429c4e059ee0f59.png