• 背景：

数据库运营环境，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. secureCRT 字体颜色、文件夹和文件显示的颜色

    secureCRT菜单栏中选择会话选项 修改显示文件夹和文件显示的颜色 修改字体样式 查看效果

  2. echarts折线图个性化填充、线条、拐点样式

    由于每组数据的拐点样式.线条颜色都不一样,所以series里的每组数据都需要单独设置样式. 首先先来看一下完成后的效果吧 具体设置如下 series: [ { name:systemName[0], ...

  3. Skynet服务器框架（十） CentOS 防火墙设置

    引言: 今天修改了 skynet 服务器的 IP 地址(即 config 文件中的 address 和 master 两项参数,IP 与当前及其的保持一致,端口号为 2017),然后使用一个简单的客户 ...

  4. 【图像处理】Haar-like特征

    特征提取的原理.代码等: 如果是白黑白,是减去一个黑的还是2个黑的,网上有不同的说法:应该需要看原论文了. 论文原文 The sum of the pixels which lie within th ...

  5. URL的应用

    1.对于Android来说,开发应用都会去访问服务器地址,那么就要连网,需要通过URL. 先new一个URL来获取路径,然后利用HttpURLConnection来连接并打开url,并通过get 请求 ...

  6. ReSharper2017.3的列对齐、排版格式、列对齐错误的修复

    ReSharper代码排版格式 列对齐 本文提供全流程,中文翻译.Chinar坚持将简单的生活方式,带给世人!(拥有更好的阅读体验 -- 高分辨率用户请根据需求调整网页缩放比例) Chinar -- ...

  7. node启动时候报错 Error: Cannot find module 'express'

    cmd命令  到目录下,然后运行 npm install -d 再 node hello.js

  8. 《DSP using MATLAB》Problem 3.17

    用差分方程两边进行z变换,再变量带换得到频率响应函数(或转移函数,即LTI系统脉冲响应的DTFT). 代码: %% ------------------------------------------ ...

  9. hdu1355

    题意:有一片矩形花生田在路的一侧,田上的整数坐标位置有0个或多个花生,现规定从路上走到田地最边上的某个格点位置.从田边上走回路上.从一个格点移动到另一个格点.采摘格点上的花生,这四种动作都要花费一单位 ...

  10. java类库 java API jar包 C语言函数库

    翁凯说:java的强大是因为类库的强大 C/C++强大是因为函数库 在程序中用到系统提供的标准函数库中的输入输出函数时 应在程序的开头写上一行:#include"stdio.h"或 ...