OB 运维 | 跑批 SQL 大量超时？集群管理避坑案例

1问题背景

凌晨 04:25 左右，OceanBase 集群业务应用端报错：

java.sql.SQLException: Timeout

OCP 告警: 04:26 存在大量 easy_connection_on_timeout_conn 的告警。

[2024-10-10 04:26:29.145046] ERROR easy_connection_on_timeout_conn (easy_connection.c:2368)
[28685][0][Y0-0000000000000000] [lt=14] [dc=0] Failed to do check_ack_timeout, and will destroy connection

原计划该时间段是跑批 SQL 任务执行时间，但检测出集群正在进行合并操作。

2应急方案

由于跑批任务优先级较高，决定暂停合并操作。

05:50 左右，在黑屏中暂停合并操作，跑批任务恢复正常。

-- sys 租户下执行
ALTER SYSTEM SUSPEND MERGE;

待跑批结束，再恢复合并操作。

-- sys 租户下执行
ALTER SYSTEM RESUME MERGE

3问题排查

待应急完成，开始分析排查问题的原因。

1. 检查 observer.log

根据 OCP 告警主机，删选对应时间的 observer 日志。

grep -i "sending error packet" observer.log

在日志中发现以下信息：

① 事务超时

② 事务回滚

当有 SQL 执行失败时，一定会打印“sending error packet”日志，其中的 err=-4012\-6224 就是语句超时和事务回滚的报错码。

2. 确认积压情况

grep ' dump tenant info(tenant={id:1001' observer.log.20241010042645
  
// 可以用如下命令检查，更加清晰
grep ' dump tenant info(tenant={id:1001' observer.log.20241010042645  | sed 's/,/,\n/g' |grep req_queue
grep ' dump tenant info(tenant={id:1001' observer.log.20241010042645  | sed 's/,/,\n/g' |grep multi_level_queue

注意：1001 换成实际 tenant_id 值。

关键指标包括 req_queue:total_size、multi_level_queue:total_size 和 group_id = *, queue_size 等，如果这些值不为 0，则说明存在积压。

更多 queue 或其他字段具体信息[1]

应用报错超时的直接原因是租户队列积压。

3. 检查 tsar 日志

tsar -d 20241010  -i 1

1. 观察到告警节点的网络重传率，在这个时间段已经超过 0.2，这个重传已经是非常高了，网络重传率较高，是 OCP 中产生大量 easy_connection_on_timeout_conn 的告警的原因。
2. tsar 监控中可以看到 04:20～04:30 时，sdb 盘使用率达到 100%，而 sdb 是 OB 的数据盘，磁盘繁忙是导致队列积压的根本原因。

结论

集群合并期间，磁盘繁忙。此时业务侧发起跑批任务，IO 压力被打满，队列发生积压。针对 RPC 类的请求，OceanBase 数据库的 ack_timeout 时间为 10 秒（超过 10 秒会断开链接），因为链接超时断开，所以业务侧的表现为 SQL 响应超时。

4优化建议

1. 调整每日合并时间，尽量避免合并期间跑批。
   • 合并时磁盘 IO 压力较大，跑批任务也会消耗系统资源，磁盘性能瓶颈导致 SQL 变慢。
   • 建议：合并与跑批任务分开进行。
2. 降低跑批并发度，并行任务改为串行。
   • 降低跑批对系统资源的压力，避免出现队列积压问题，进而导致跑批超时。
3. 业务拆分。
   • 目前集群体量较大，跑批，合并，备份等时间冲突，建议进行业务拆分。