解析 tshark 工具生成的 MySQL SQL、解析响应时间(响应时间按照 SQL 第一次返回数据包计算,不考虑应用流式读取数据时发送结果的时间)
tshark 需提前安装:
yum install -y wireshark # Centos 7 自带的版本较低,但也能工作,建议编译安装 3.2.3 版本
该方式会直接生成 parse-tshark 工具可读取的文件,生成的文件比较小,但在资源不够时对 MySQL 性能影响大(不推荐在生产使用)
sudo tshark -i eth0 -Y "mysql.query or ( tcp.srcport==3306)" -d tcp.port==3306,mysql -o tcp.calculate_timestamps:true -T fields -e tcp.stream -e tcp.len -e tcp.time_delta -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport -e frame.time_epoch -e mysql.query -E separator='|' >> tshark.log
该方式生成的文件比较大,但对生产性能影响小
该命令只是根据 3306 端口和 eth0 网卡抓包,以抓取 1 小时为例(每个文件大约 2000MB,最多生成 200 个)
sudo tshark -i eth0 -f "tcp port 3306" -a duration:3600 -b filesize:2000000 -b files:200 -w ts.pcap
该命令针对抓包生成的 pcap 文件进行处理,处理成 parst-tshark 工具可读的文件(建议将这些文件传输到回放服务器处理)
for i in `ls -rth ts*.pcap`
do
sudo tshark -r $i -Y "mysql.query or ( tcp.srcport==3306)" -d tcp.port==3306,mysql -o tcp.calculate_timestamps:true -T fields -e tcp.stream -e tcp.len -e tcp.time_delta -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport -e frame.time_epoch -e mysql.query -E separator='|' >> tshark.log
done
由于 tshark 抓包时获取 user/db 信息过于复杂、且存在局限性,所以通过工具每隔 500ms 获取一次 MySQL 数据库的 processlist 视图信息,通过源端 IP+端口 与 processlist 视图中的 host 匹配
./parse-tshark -mode getmysql -dbinfo 'username:password@tcp(localhost:3306)/information_schema' -output host.ini
注意:该工具运行时间需要和 tshark 抓包时间一样久,才能获取完整的 user/db 信息
如抓取的是 mycat 中间件流量,则需要使用如下命令:
./parse-tshark -mode getmycat -dbinfo 'username:password@tcp(localhost:9066)' -output host.ini
注意:mycat show @@connection 默认没记录 user 信息,所以在 host.ini 中显示的是 null
./parse-tshark -mode parse2cli -parsemode 1 -tsharkfile ./tshark.log
./parse-tshark -mode parse2file -parsemode 1 -tsharkfile ./tshark.log -hostfile host.ini -replayfile ./tshark.out -defaultuser user_null -defaultdb db_null
说明:sql-replay 是一个回放 MySQL 慢查询日志的工具:sql-replay
- 测试环境: 8C VM
- MySQL: 8.0.33
- tshark: 3.2.3
- 测试用例: sysbench
并发 | 初始 TPS | CPU | TPS: tshark port | TPS: tshark port+mysql | TPS: tcpdump port |
---|---|---|---|---|---|
1 | 148.28 | 25.6% | 143.56 | 138.20 | 145.14 |
5 | 342.12 | 37.9% | 324.85 | 320.24 | 326.13 |
10 | 525.76 | 47.7% | 495.98 | 457.25 | 511.26 |
50 | 1103.53 | 73.9% | 1017.46 | 871.50 | 1045.98 |
100 | 1301.19 | 79.8% | 1237.04 | 968.46 | 1255.13 |
说明
- 低并发+资源充足时,“tshark 抓包方式一”、“tshark 抓包方式二”、“tcpdump 抓包方式”三者对 MySQL 的影响均不大
- 高并发+资源不够时,“tshark 抓包方式一”有 7% 影响,“tshark 抓包方式二”有 21% 影响,“tcpdump 抓包方式”有 5% 影响
sysbench 50 并发 * select_random_points * 1800 秒,总共执行 45757727 条 SQL
parse-tshark 最终解析出 45747497 条 SQL
- 负载均衡节点抓包时,无法根据 host:port 来获得 id,user,db 等信息,只能在 parse2file 时使用 -defaultuser -defaultdb 手工指定
- mycat 节点抓包时,无法获取到 user 信息,只能在 parse2file 时 -defaultuser 手工指定
- 上游是 prepare 预编译 SQL 时,解析出来的 SQL 无法执行,在 sql-replay 时这部分 SQL 在数据库中会报错
- 抓包开始到抓包过程结束还没执行完成的 SQL,不会解析到输出文件中