如何抓包来确定数据库处理延迟

发表于 分类于 阅读次数： 本文字数： 729 阅读时长 ≈ 2 分钟

数据同步中的延迟问题

对于数据同步工具而言，最常遇到的问题就是写入延迟问题。一般监控展示的延迟信息均是端到端的延迟。但是一旦出现延迟，要定位延迟具体发生在端到端链路中哪一个环节是有一定复杂性的。
一般同步工具都会提供commit日志，写出数据到对端的时候记录一个日志，然后收到响应的时候再记录一个时间。两者时间相减得到的RTT时间，即数据在网络上传输加上对端数据库处理的耗时。
image.png
一般而言通过commit日志，结合一些ping和retran的信息已经有足够的理由证明是对端数据库处理慢导致了。但是产品在实际面向客户时，客户很多时候对同步工具产品本身提供的日志信服度不够。如果对端数据库也没有全量SQL审计这样的能力，这种时候如何提供更有信服力的证据呢？本节我们就说明如何通过抓包来判断数据库处理的耗时情况。

抓包

执行抓包命令

1
2
3
4
5
# 下面案例中，数据同步程序所在机器为10.30.1.138，对端数据库机器为58.58.13.77
# 网卡通过ifconfig看看主网卡是不是eth0这个名字
tcpdump -i eth0   host 10.30.1.138 and 58.58.13.71  -w db.cap

# 这个命令持续运行，结束的时候ctrl+c结束即可

分析

打开抓包文件

分析抓包文件建议使用wireshark这个图形化工具，win和mac都有

过滤协议包

wireshark打开抓包文件，按照数据库协议进行顾虑，比如对端是postgresql或者greenplum，走的是pgsql协议，顶部过滤栏可以进行过滤
image.png

新增自定义列

新增一个自定义列 frame.time_delta_displayed，这个在页面上右键可以编辑并且新增列.

Tips

  • frame.time_delta_displayed: 相较于上一个显示帧的时间增量。用displayed主要考虑有过滤条件导致显示帧不连续的情况

image.png

寻找交接处

数据库协议会把包含SQL的数据包先从client全部发送给server，然后再接收server的response。因此在列表中寻找到对端数据库回包的第一个packet。如果这个包是在数据库这一侧抓取的，这里我们得到的delta时间就是数据库从系统网络缓冲区取数据再到数据库处理完成回包的时间了。
一般操作系统如果没有明显指标异常，如果这个延迟时间比较长基本上也可以断定数据库处理的速率比较慢。一般数据库处理一批数据的时间在10ms以内是比较高效的。

image.png