数据库优化经典案例
• 超时重传
TCP每发送一个报文段,就对这个报文段设置一次计时器。 当计时器超时而没有收到确认时,就重传该报文。
• 快重传
在发送端一连收到4个ack报文,其中3个重复报文时,就 立即重传相应的报文而不等到定时器超时。
TCP重传会对数据库产生什么影响
• 数据库大量慢查
模拟40%的重传 $sudo tc qdisc add dev eth0 root netem loss 40%
TCP重传会对数据库产生什么影响
• 大量SQL被kill
• 每个实例部署了sql killer 当实例中存在执行时间超过1秒的SQL,立即执行kill query thread_id。
• 收到大量SQL被kill的告警
TCP重传会对数据库产生什么影响
• 大量SQL被kill
• 日志里面的thread id都是同一个 • 执行时间超过killer的阈值,以1秒递增
以下案例均在事务开始之后
• 假如强制关闭应用 • 假如client机器突然崩溃宕机/断电 • 假如网络发生抖动/网卡发生故障
如果事务中发生了网络异常
模拟client突然宕机
10:00:00 10:00:10
Client 192.168.56.102
begin; select * from zandb.t1 for update;
如果事务中发生了网络异常
事务什么时候会退出?
2. 等待TCP超时
修改TCP超时 # echo 60 > /proc/sys/net/ipv4/tcp_keepalive_time # echo 7 > /proc/sys/net/ipv4/tcp_keepalive_intvl # echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes
power off
Server 192.168.56.101
断电
如果事务中发生了网络异常
MySQL Server事务信息
如果事务中发生了网络异常
MySQL Server 主机TCP连接信息
如果事务中发生了网络异常
启动一个新的client,对t1表进行加锁需要等待
如果事务中发生了网络异常
服务端为什么没有退出这个事务呢?
TCP 新建连接需要三次握手 TCP 关闭连接需要四次挥手
如果事务中发生了网络异常
如果事务中发生了网络异常
网络异常的时候,TCP连接的状态还是 ESTABLISHED,说明了任何一方都没有发送FIN 包,服务端还在等待CLIENT发送数据,此时的 MySQL事务无法直接退出。
如果事务中发生了网络异常
如果事务中发生了网络异常
事务什么时候会退出?
开始抓包 # tcpdump host 192.168.56.102 -s 0 -w /tmp/tcp_timeout.pcap
如果事务中发生了网络异常
事务什么时候会退出?
3. 主动kill 异常会话 mysql > kill thread_id;
TCP重传会对数据库产生什么影响
些收尾工作完成后,SQL语句才会退出。
大量删除导致的SQL慢查
现象描述
1. 执行sbtest1表的部分查询非常慢,状态为 Sending data 2. 执行除sbtest1表外的其他表查询都非常快
大量删除导致的SQL慢查
分析问题
1. 数据库的隔离级别为RR 2. 查询监控慢查的量是大量删除操作之后开始的 3. 询问业务方,得知该表会经常执行删除旧数据的操作 4. History list length 非常大,达到几万,并且一直在增长 5. 查询innodb_trx 表发现有一个事务,很久没有提交
事务什么时候会退出?
1. MySQL参数 wait_timeout(默认8小时) 表示的是MySQ L的一个连接空闲超过8小时, M y S Q L 自动断开该连接
如果事务中发生了网络异常
事务什么时候会退出?
2. 等待TCP超时
TCP 超时参数 /proc/sys/net/ipv4/tcp_keepalive_time = 7200(等待空闲时间秒) /proc/sys/net/ipv4/tcp_keepalive_intvl = 75(探测间隔秒) /proc/sys/net/ipv4/tcp_keepalive_probes = 9(探测次数)
TCP重传会对数据库产生什么影响
• 大量SQL被kill
在执行 kill query thread_id 时,MySQL 做了两件事: 1. 把对应的session的运行状态值(killed )改成THD::KILL_QUERY 2. 给对应的session的执行线程发一个信号。 被kill的线程需要在埋点的地方/可唤醒的等待判断线程状态
数据库优化经典案例
技术创新 变革未来
案例列表
• 如果事务过程中发生了网络异常 • TCP重传会对数据库产生什么影响 • 大量删除导致的SQL慢查 • 一次奇怪的SQL慢查的分析 • 一次SQL RT增加的问题排查 • 利用strace利器解决性能问题 • 如何去定位生了网络异常
TCP重传会对数据库产生什么影响
• 大量SQL被kill
为啥执行kill query thread_id无效
• 线程没有执行到判断线程状态的逻辑。读写 IO 的函数一直无法返
回,线程一直在等待进入innodb等,会导致不能及时判断线程的状 态。
• 终止逻辑耗时较长。例如大事务回滚,临时文件删除等。需要等这
TCP重传会对数据库产生什么影响
• 数据库大量慢查
TCP重传会对数据库产生什么影响
• 数据库大量慢查
在网络发生重传的时候,SQL的执行结果发送给客户端的时 候需要通过TCP重传来完成,SQL的执行state表现为 Sending to client。
如果一个block在net_write_timeout时间内都没有完成发送, SQL执行将会中断,抛出1161错误(Got timeout writing communication packets)
大量删除导致的SQL慢查
搭建模拟测试环境,利用sysbench创建一张48730893行的sbtest1表