• 背景:

数据库运营环境,zabbix mysql响应时间告警,响应时间超时

  • zabbix监控

  • tcprstart 直接抓包响应时间看到每5秒钟就一次,与zabbix监控一致
[root@slave1(35.101) /r2/monitor]# tcprstat -l 192.168.3.101  -p 3306 -t 1 -n 0
timestamp count max min avg med stddev 95_max 95_avg 95_std 99_max 99_avg 99_std
1540537920 0 0 0 0 0 0 0 0 0 0 0 0
1540537921 7 95 54 77 73 16 92 74 15 92 74 15
1540537922 0 0 0 0 0 0 0 0 0 0 0 0
1540537923 0 0 0 0 0 0 0 0 0 0 0 0
1540537924 0 0 0 0 0 0 0 0 0 0 0 0
1540537925 0 0 0 0 0 0 0 0 0 0 0 0
1540537926 0 0 0 0 0 0 0 0 0 0 0 0
1540537927 0 0 0 0 0 0 0 0 0 0 0 0
1540537928 1 5000198 5000198 5000198 5000198 0 0 0 0 0 0 0
1540537929 0 0 0 0 0 0 0 0 0 0 0 0
1540537930 0 0 0 0 0 0 0 0 0 0 0 0
1540537931 0 0 0 0 0 0 0 0 0 0 0 0
1540537932 0 0 0 0 0 0 0 0 0 0 0 0
1540537933 1 5000178 5000178 5000178 5000178 0 0 0 0 0 0 0
1540537934 0 0 0 0 0 0 0 0 0 0 0 0
1540537935 0 0 0 0 0 0 0 0 0 0 0 0
1540537936 0 0 0 0 0 0 0 0 0 0 0 0
1540537937 0 0 0 0 0 0 0 0 0 0 0 0
1540537938 1 5000162 5000162 5000162 5000162 0 0 0 0 0 0 0
1540537939 0 0 0 0 0 0 0 0 0 0 0 0
1540537940 0 0 0 0 0 0 0 0 0 0 0 0
1540537941 0 0 0 0 0 0 0 0 0 0 0 0
1540537942 0 0 0 0 0 0 0 0 0 0 0 0
1540537943 1 5000171 5000171 5000171 5000171 0 0 0 0 0 0 0
1540537944 0 0 0 0 0 0 0 0 0 0 0 0
1540537945 0 0 0 0 0 0 0 0 0 0 0 0
1540537946 0 0 0 0 0 0 0 0 0 0 0 0
1540537947 0 0 0 0 0 0 0 0 0 0 0 0
1540537948 1 5000192 5000192 5000192 5000192 0 0 0 0 0 0 0
1540537949 0 0 0 0 0 0 0 0 0 0 0 0
1540537950 0 0 0 0 0 0 0 0 0 0 0 0
1540537951 0 0 0 0 0 0 0 0 0 0 0 0
1540537952 0 0 0 0 0 0 0 0 0 0 0 0
1540537953 1 5000175 5000175 5000175 5000175 0 0 0 0 0 0 0
1540537954 0 0 0 0 0 0 0 0 0 0 0 0
1540537955 0 0 0 0 0 0 0 0 0 0 0 0
1540537956 0 0 0 0 0 0 0 0 0 0 0 0
1540537957 0 0 0 0 0 0 0 0 0 0 0 0
1540537958 1 5000186 5000186 5000186 5000186 0 0 0 0 0 0 0
1540537959 0 0 0 0 0 0 0 0 0 0 0 0
1540537960 0 0 0 0 0 0 0 0 0 0 0 0
1540537961 0 0 0 0 0 0 0 0 0 0 0 0
1540537962 0 0 0 0 0 0 0 0 0 0 0 0
1540537963 1 5000201 5000201 5000201 5000201 0 0 0 0 0 0 0
1540537964 0 0 0 0 0 0 0 0 0 0 0 0
1540537965 0 0 0 0 0 0 0 0 0 0 0 0
1540537966 0 0 0 0 0 0 0 0 0 0 0 0
1540537967 0 0 0 0 0 0 0 0 0 0 0 0
1540537968 1 5000146 5000146 5000146 5000146 0 0 0 0 0 0 0
1540537969 0 0 0 0 0 0 0 0 0 0 0 0
1540537970 0 0 0 0 0 0 0 0 0 0 0 0
1540537971 0 0 0 0 0 0 0 0 0 0 0 0
1540537972 0 0 0 0 0 0 0 0 0 0 0 0
1540537973 1 5000173 5000173 5000173 5000173 0 0 0 0 0 0 0
1540537974 0 0 0 0 0 0 0 0 0 0 0 0
1540537975 0 0 0 0 0 0 0 0 0 0 0 0
1540537976 0 0 0 0 0 0 0 0 0 0 0 0
1540537977 0 0 0 0 0 0 0 0 0 0 0 0
1540537978 1 5000229 5000229 5000229 5000229 0 0 0 0 0 0 0
1540537979 0 0 0 0 0 0 0 0 0 0 0 0
1540537980 0 0 0 0 0 0 0 0 0 0 0 0
1540537981 0 0 0 0 0 0 0 0 0 0 0 0
1540537982 0 0 0 0 0 0 0 0 0 0 0 0
1540537983 1 5000144 5000144 5000144 5000144 0 0 0 0 0 0 0
1540537984 0 0 0 0 0 0 0 0 0 0 0 0
1540537985 1 357 357 357 357 0 0 0 0 0 0 0
1540537986 0 0 0 0 0 0 0 0 0 0 0 0
1540537987 0 0 0 0 0 0 0 0 0 0 0 0
1540537988 1 5000196 5000196 5000196 5000196 0 0 0 0 0 0 0
  • 通过tcpdump 抓包
[root@slave1(35.101) /r2/monitor]#  tcpdump -i em4 -s 3000 port 3306 -w  em4sql.pcap
tcpdump: listening on em4, link-type EN10MB (Ethernet), capture size 3000 bytes
^C576 packets captured
591 packets received by filter
0 packets dropped by kernel
  • 使用wireshark 分析em4sql.pcap

可以看响应的时间

可以看到实际的sql

mysql响应时间超时排查的更多相关文章

  1. 一个诡异的MySQL查询超时问题,居然隐藏着存在了两年的BUG

    这一周线上碰到一个诡异的BUG. 线上有个定时任务,这个任务需要查询一个表几天范围内的一些数据做一些处理,每隔十分钟执行一次,直至成功. 通过日志发现,从凌晨5:26分开始到5:56任务执行了三次,三 ...

  2. 手把手教你定位线上MySQL锁超时问题,包教包会

    昨晚我正在床上睡得着着的,突然来了一条短信. 什么?线上的订单无法取消! 我赶紧登录线上系统,查看业务日志. 发现有MySQL锁超时的错误日志. 不用想,肯定有另一个事务正在修改这条订单,持有这条订单 ...

  3. MySQL 各种超时参数的含义

    MySQL 各种超时参数的含义 今日在查看锁超时的设置时,看到show variables like '%timeout%';语句输出结果中的十几种超时参数时突然想整理一下,不知道大家有没有想过,这么 ...

  4. Mysql 高负载排查思路

    Mysql 高负载排查思路 发现问题 top命令 查看服务器负载,发现 mysql竟然百分之两百的cpu,引起Mysql 负载这么高的原因,估计是索引问题和某些变态SQL语句. 排查思路 1. 确定高 ...

  5. MySQL连接问题【如何解决MySQL连接超时关闭】

    --MySQL连接问题[如何解决MySQL连接超时关闭] ------------------------------------------------转载 最近做网站有一个站要用到WEB网页采集器 ...

  6. RPC服务超时排查思路

    RPC服务超时排查思路- 1.查看服务提供者日志相关信息进行排查- 2.查看消费者的超时时间设置是否合理- 3.查看服务提供者业务逻辑是否有DB操作,有的话看是否有慢SQL- 4.查看服务提供者业务逻 ...

  7. Tcprstat测试mysql响应时间

    Tcprstat测试mysql响应时间 一.tcprstat工具安装与使用 tcprstat 是一个基于 pcap 提取 TCP 应答时间信息的工具,通过监控网络传输来统计分析请求的响应时间. 使用方 ...

  8. mysql连接超时的问题

    使用Hibernate + MySQL数据库开发,链接超时问题: com.mysql.jdbc.CommunicationsException: The last packet successfull ...

  9. 记一次mysql请求超时甩锅历程

    今天下午业务找我说是线上环境一个mysql库很慢,请求出现了大量的超时,让帮忙看看,以下为查找过程及甩锅过程. 1. mysql请求超时,ok,我们所有线上mysql都是开启了慢查询日志的,查找慢查询 ...

随机推荐

  1. Eclipse js报错问题解决办法

    最近在Eclipse中导入新项目后会发现js报错,但是不影响程序的运行,但是对于程序员的我们来说多少还是比较在意代码前面的红色的X的,有木有??? 上网也查了很多方法,对于其中一种方法表示不能完全解决 ...

  2. 算法训练 Lift and Throw

    算法训练 Lift and Throw   时间限制:3.0s   内存限制:256.0MB      问题描述 给定一条标有整点(1, 2, 3, ...)的射线. 定义两个点之间的距离为其下标之差 ...

  3. exit和return

    函数名: exit() 所在头文件:stdlib.h(如果是”VC6.0“的话头文件为:windows.h) 功 能: 关闭所有文件,终止正在执行的进程. exit(1)表示异常退出.这个1是返回给操 ...

  4. 转:sqlplus使用总结

    为什么我要使用sqlplus: SQLPLUS很多人用的并不多,在我观察周围来看,很多人都在使用PLSQL DEVELOPER,尤其是开发人员,更是如此,那学习SQLPLUS有啥好处呢?在我看来有如下 ...

  5. [LeetCode&Python] Problem 682. Baseball Game

    You're now a baseball game point recorder. Given a list of strings, each string can be one of the 4 ...

  6. 51Nod:独木舟问题(贪心)

    n个人,已知每个人体重,独木舟承重固定,每只独木舟最多坐两个人,可以坐一个人或者两个人.显然要求总重量不超过独木舟承重,假设每个人体重也不超过独木舟承重,问最少需要几只独木舟? 输入 第一行包含两个正 ...

  7. 工具运行过程中,CPU占用过高的分析定位

    之前使用Java Swing开发了一款设备档案收集工具.支持多台设备同时收集,每个设备使用一个线程.在同时收集多台设备信息时,发现CPU占用率居然达到了97%,而且高居不下.显然这样的性能是令人无法忍 ...

  8. set 与 map 的第一次尝试

    map 杭电6015http://acm.hdu.edu.cn/showproblem.php?pid=6015 基本用法:map<string,int>mp;   mp[class[ i ...

  9. 【问题】C4D中设置了界面颜色,如何恢复默认?

    由于C4D没有恢复默认设置的选项,恢复默认的时候比较麻烦,这里简单删除一下配置文件就好了. 1.打开C4D设置,点击下面的[打开配置文件夹],并关掉C4D. (即C:\Users\你的用户名\AppD ...

  10. day13 python学习 迭代器,生成器

    1.可迭代:当我们打印 print(dir([1,2]))   在出现的结果中可以看到包含 '__iter__', 这个方法,#次协议叫做可迭代协议 包含'__iter__'方法的函数就是可迭代函数 ...