如何剖析C++/Unix阻塞或休眠代码？数据库优化后耗时未降排查

1. 实时追踪线程阻塞状态 #

• 用pstack <进程PID>（Linux）或gdb attach <PID>后执行thread apply all bt，定期采样（比如每隔1分钟执行一次），统计各线程的调用栈。如果大量线程卡在pthread_mutex_lock、sem_wait或连接池获取方法上，说明存在同步阻塞；如果卡在recv、send或数据库驱动的网络调用上，说明是网络/数据库响应阻塞。
• 使用perf trace -p <PID>追踪系统调用的耗时，重点关注epoll_wait、poll、recvfrom、sendto等网络IO调用，以及pthread_mutex_lock、sem_timedwait等同步调用，查看这些调用的平均耗时和最大耗时，定位阻塞点。

2. 数据库交互的细粒度计时 #

• 在数据库访问代码的关键节点添加轻量级计时：记录连接池获取的开始/结束时间、SQL语句发送开始/结束时间、结果接收开始/结束时间，计算各阶段的耗时。比如：

  auto conn_start = std::chrono::steady_clock::now();
  auto conn = connection_pool->get();
  auto conn_end = std::chrono::steady_clock::now();
  LOG_INFO("获取连接耗时: %.3fms", 
           std::chrono::duration_cast<std::chrono::milliseconds>(conn_end - conn_start).count());
  
  auto sql_start = std::chrono::steady_clock::now();
  auto result = conn->execute(sql);
  auto sql_end = std::chrono::steady_clock::now();
  LOG_INFO("SQL执行耗时: %.3fms", 
           std::chrono::duration_cast<std::chrono::milliseconds>(sql_end - sql_start).count());
  

• 统计这些计时数据的分布（最大值、95分位值），如果连接获取耗时波动大且均值高，说明连接池存在争用或配置不合理；如果SQL执行耗时高，结合网络抓包排查数据库响应延迟。

3. 网络隧道与数据库通信分析 #

• 用tcpdump -i <网卡> host <数据库服务器IP> and port <数据库端口>抓包，导出后分析：
  • 计算每个数据库请求（比如MySQL的Query包）和响应（Result包）的时间差，看是否存在异常高的往返延迟。
  • 检查是否有频繁的TCP重连（大量SYN包）、丢包（重传包）或TCP窗口过小导致的传输阻塞。
• 测试隧道基础性能：在应用服务器和数据库服务器之间用iperf测试带宽和延迟，确认隧道本身是否存在瓶颈。

4. 磁盘IO瓶颈排查 #

• 在数据库服务器上执行iostat -x 1，观察%iowait（IO等待占CPU时间的比例）、await（IO请求平均等待时间）、svctm（IO请求平均服务时间）。如果%iowait持续高于10%且await远大于svctm，说明数据库磁盘写入存在瓶颈（比如批量写入触发频繁刷盘）。
• 应用服务器上用vmstat 1查看bi/bo（块设备读写速率）和wa（IO等待时间），排查本地日志、临时文件等是否存在IO阻塞。

5. 连接池有效性验证 #

• 检查连接池配置：确认最大连接数是否匹配线程数量，是否设置了合理的连接超时时间。如果线程数远大于最大连接数，会导致大量线程等待获取连接。
• 添加连接池状态统计：记录当前活跃连接数、等待队列长度，定期输出到日志。如果等待队列长度持续不为0，说明连接池容量不足。
• 排查连接泄漏：在连接销毁/归还时计数，确保每个获取的连接都被正确归还到池子里。

6. 多线程同步与锁争用分析 #

• 使用perf lock record -p <PID>记录锁的争用情况，然后用perf lock report查看哪些锁的等待时间最长。重点关注连接池内部的同步锁、MQ客户端的锁等。
• 在代码中对同步操作（比如信号量、互斥锁）添加计时，统计等待时长，定位是否存在长时间的锁阻塞。

7. MQ相关瓶颈排查 #

• 如果任务涉及MQ，记录消息发送、接收、ACK的耗时，查看是否存在等待ACK超时、队列满导致的阻塞。
• 检查MQ服务器的监控指标：比如消息堆积量、发送/接收速率、Broker的CPU/IO负载，确认MQ本身是否存在瓶颈。

内容的提问来源于stack exchange，提问作者Synopsis