案例背景
某保险机构客户的数据中台，自系统上线后不久，会定期的用 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>