写入性能断崖式下降的

OceanBase 技术问题
#1

OceanBase 版本：4.2.1.0 社区版
集群规模：3 节点（3 副本），每节点 32C/128G/2T SSD
业务场景：金融交易系统，每日峰值写入 TPS 约 1.5 万，查询 TPS 约 8 千
部署方式：Docker 容器化部署，使用本地盘存储
运行时长：集群已稳定运行 6 个月

2026 年 5 月 10 日上午 9:30，业务监控突然报警：

  1. 数据库写入响应时间从正常的 2-5ms 飙升至 500-2000ms
  2. 写入 TPS 从 1.2 万骤降至 2000 左右
  3. 部分业务交易超时失败，失败率达到 15%
  4. 奇怪的是：查询性能完全正常，响应时间仍保持在 1-3ms
  5. 集群各节点 CPU 使用率仅 30-40%，内存使用率 60%，磁盘 IO 使用率 20%，无明显资源瓶颈

基础监控检查集群状态正常，所有节点在线，资源使用率均在安全阈值内。所有慢 SQL 都是 INSERT/UPDATE 操作，SELECT 语句无异常。事务等待 出现大量ob_log_sync_wait等待事件，占比超过 90%。日志同步状态所有副本日志同步正常，lag 均小于 10ms。

7 个赞
#3

大概问题出在日志同步环节，但常规监控显示同步正常，先查看 OBServer 详细日志，在出现问题的节点上查看 observer.log，再检查文件系统 inode 使用情况，看看文件系统 inode是否已耗尽，查看占用大量 inode 的文件，分析日志目录结构，检查日志轮转配置，看看是否Docker 容器日志驱动与 OceanBase 日志轮转机制冲突，OceanBase 的日志轮转机制是：当observer.log达到log_file_size时，将其重命名为observer.log.1，然后创建新的observer.log，但 Docker 使用的json-file日志驱动会**持续持有打开的文件句柄，当 OceanBase 重命名日志文件时，Docker 仍然持有原来的文件句柄，导致文件无法被真正删除，更严重的是：每次日志轮转，都会创建一个新的文件，但旧文件因为被 Docker 持有而无法释放，日积月累，日志目录下产生了上百万个小文件，耗尽了文件系统的 inode，当 inode 耗尽时，OceanBase 无法创建新的事务日志文件，导致写入操作阻塞，但查询操作不受影响。解决方案是：修改 Docker 容器启动命令，禁用 Docker 对 OceanBase 日志的采集或者修改 daemon.json，全局配置 Docker 日志驱动。 配置 OceanBase 独立日志轮转，使用 logrotate 工具来管理 OceanBase 日志

4 个赞
#4

感谢老师

3 个赞
#5

我去操作试试

2 个赞
#6

金融场景应该物理部署，不理解为什么要docker部署？

2 个赞
#7

这去研究一下

1 个赞
#8

学习了

#9

借着机会， docker换裸金属。 用了docker就对性能又点儿包容性。。

#10

太专业了，学习

#11

太专业了，学习