mysql 请求时间很长_记一次mysql请求超时甩锅历程

这篇博客记录了一次排查线上MySQL数据库出现大量请求超时的问题。首先检查了慢查询日志,未发现超时查询;接着分析了InnoDB状态、锁定情况和事务,均未发现异常。网络状况也被确认为正常。最后通过tcpdump抓包发现请求处理时间远低于超时阈值,从而排除了数据库本身的故障,将问题定位到业务层面。
摘要由CSDN通过智能技术生成

今天下午业务找我说是线上环境一个mysql库很慢,请求出现了大量的超时,让帮忙看看,以下为查找过程及甩锅过程。

1. mysql请求超时,ok,我们所有线上mysql都是开启了慢查询日志的,查找慢查询日志文件,没有发现所说的超时的查询。

2. 那就再看看有没有没有提交的事务,死锁等情况发生吧。

show engine innodb status; 发现最近的一次死锁是1个月之前的。

select * from information_schema.locks;

select * from information_schema.lock_waits;

select * from information_schema.trx;  无异常。

3. 经过上面两步,基本可以确定mysql无异常,随后告知运维,让运维帮忙确认网络情况。

4. 5分钟后,运维告知网络一切正常,但是业务日志中还是存在大量超时。

5. 那就抓个包吧,询问业务报超时的服务器ip,使用tcpdump抓个包看看一个请求从进入数据库服务器到返回到底用了多长时间:

tcpdump -i eth0 host 10.6.77.73 -A > tcp.pkg

最终发现一个请求从进入到返回不到0.1s,ok,告知业务方。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值