背景描述

某保险客户数据中台，定期使用obload将上游业务数据导入到OceanBase数据库中，系统上线不久，应用服务器容器频繁出现memory和cpu资源持续升高直至系统夯住不可用的异常情况。

memory 利用率

cpu 利用率

数据不能更新已经影响下游业务处理，问题比较严重，我们紧急上线排查，分析发现客户应用是通过java程序调用shell脚本，再执行obloader命令，可能会同时出现多个任务并发导数据的情况。在并发导数据场景下，系统出现大量obloader 进程，应用java 程序夯住不可用，最终导致容器OOM重启，客户是不可接受的。

问题排查

我们拿到客户的shell脚本和数据文件，在线下进行验证尝试复现，过程如下

• 验证一：独立运行obloader工具
• 现象：独立运行obloader工具没有发生夯住的现象，可以确认工具内部是可以正常工作的。

研发人员需要结合业务系统产生的数据格式决定如何使用obloader工具；在命令行参数中加上--trail-delimiter 导入业务数据，导入可以发现文件中存在大量脏数据。

• 验证二：使用shell脚本运行obloader工具
• 现象：摄影shell脚本运行obloader工具没有发生夯住的现象，但是导入速度比直接运行obloader 工具慢10多秒，同样可以排除obloader工具内部没有夯住的问题。

• 验证三：提交多份文件，使用java程序运行obloader 工具
• 现象：导入速度比直接运行obloader 工具慢1分钟，同时发现业务产生的数据文件中格式严重 不一致，有的行有29列，有的行有32列，数据无法正常导入，工具打印大量的错误日志，java 程序夯住。

解决方案

上述验证结论可以推测，控制台大量错误日志输出，导致java调用程序夯住，而通过shell窗口运行脚本或者工具，并未出现夯住的现象。为了进一步验证推测，我们再进行下一步的验证，将运行脚本中的命令产生的stderr/stdout重定向到指定文件中，避免向控制台输出。测试验证推理，至此问题原因定位，修复方案如下

1、上游业务检查推送的数据文件格式，避免出现格式不正确的脏数据问题。

2、java程序去到log4j2.xml配置中的<AppenderRef ref="ConsoleAppender" />，避免控制台打印大量错误日志。

3、并发限制，避免同时大量调用obloader导数据，避免cpu、memory 资源不足。

log4j2.xml配置文件修改

修改前
<Logger name="com.oceanbase.tools.loaddump" additivity="false" level="INFO">
<AppenderRef ref="ConsoleAppender" />
<AppenderRef ref="InfoRoutingAppender" />
<AppenderRef ref="WarnRoutingAppender" />
<AppenderRef ref="ErrorRoutingAppender" />
</Logger>

去掉了 <AppenderRef ref="ConsoleAppender" />
修改后
<Logger name="com.oceanbase.tools.loaddump" additivity="false" level="INFO">
<AppenderRef ref="InfoRoutingAppender" />
<AppenderRef ref="WarnRoutingAppender" />
<AppenderRef ref="ErrorRoutingAppender" />
</Logger>

补充说明

客户数据文件格式不正确问题：怎么理解行尾有分隔符？数据样例如下：

行尾有分隔符的数据
1^!我爱中国^!

行尾没有分隔符的数据
1^!我爱中国

对于行尾有分隔符的数据，默认是把最后的分隔符也当作有效的分隔符处理，所以解析出来的数据是
1，我爱中国，<空格>   三列数据，
实际上业务没有最后一列数据，那么就加上 --trail-delimiter 把最后一列值： <空格> 丢掉。