作者： 数据源的 TiDB 学习之路原文来源：https://tidb.net/blog/c9cd454a

问题现象

使用 sysbench + haproxy 对 TiDB 进行压测，运行 57 小时后遇到报错。

问题分析步骤

1. 根据报错提示 error 2013(Lost connection to MySQL server during query)，判断是客户端连接中断，对应正在执行的语句为 SELECT SUM(k) FROM sbtest3 WHERE ID BETWEEN 10060469 AND 10060568。

2. 收集 Clinic，并上传 Clinic Server。

3. 首先查看 TiDB 监控，判断问题发生在 02:01 分左右，当时发生了 Slow Query，随之业务几乎停止，判断可能跟 Slow Query 有关。

1. 查看 Performance 监控，在 02:01~02:02 分之间，确实发生了连接中断，与压测报错一致。

1. 在报错之前，集群整体的内存比较平稳，CPU 基本处于满负荷运行状态。

1. 查看 Slow Query 监控，发现压测报错的语句显示在慢查询列表中，进一步查看执行计划发现时间主要消耗在 Coprocesor Executor Time 部分。

1. 进一步查看 TiDB 日志文件，确认 183 节点 TiDB 日志中存在连接报错的现象，连接报错前存在慢 SQL，与压测一致，从日志看报错语句的执行耗时为 1m0.073155353s，导致 write tcp 192.168.162.183:3306->192.168.26.99:53518 中断，即 TiDB Server -> Haproxy 连接中断。

2. 从上述分析来看，判断可能是 Haproxy 中存在客户端连接配置 timeout，且 timeout 设置为 60 秒，查看 HAProxy 配置，发现确实如此， HAProxy 中均使用默认的客户端配置。建议根据 HAProxy 在 TiDB 中的最佳实践 配置来进行，或者不使用 HAProxy 来进行压测。

1. 关于 SQL 语句执行耗时较长的原因，判断可能与集群长时间处于 CPU 满负载工作有关，另外从监控中也能看到网络连接有存在少量波动的情况。

分析结论

Sysbench 报错的原因是遇到慢 SQL 执行超过 60 秒，达到默认的 HAProxy 中的 timeout client 配置，导致 HAProxy 主动中断连接报错。关于此报错的解决方法有：

1. 修改 HAProxy 默认配置，参考 HAProxy 在 TiDB 中的最佳实践
   

2. 不使用 HAProxy 进行分发， sysbench 本身可以配置为多 IP 方式均衡到各 TiDB 节点

3. sysbench 运行命令添加 –mysql-ignore-errors，确保 sysbench 客户端不退出