在一次使用datax从gbase读数据写入sqlserver，长时间日志显示task的各项指标都是0，报“java.lang.OutOfMemoryError: GC overhead limit exceeded”。调整了reader的fetchSize和writer的batchSize，比较极端降到了1依然报错。
开始跟着网上的资料排查问题
首先在启动脚本中添加了-XX:-UseGCOverheadLimit命令。
python datax.py --jvm="-Xms3G -Xmx3G -XX:-UseGCOverheadLimit" ../job/oom.json
报错信息变成了
“java.lang.OutOfMemoryError: Java heap space”
然后尝试增加了datax的jvm内存
python datax.py --jvm="-Xms3G -Xmx3G" ../job/oom.json
最后还是会报OOM。
只能去找究竟是那一部分代码产生了异常。
找到datax运行的进程编号 6630，把jvm的运行快照dump下来。
jmap -dump:format=b,file=/tmp/6630_jmap_dump.hprof 6630
导入到MemoryAnalyzer里。
先看Histogram，列出内存中的对象，对象的个数以及大小。
打开Dominator Tree，可以看到这个Ox752227ea8的线程，以及线程里的一个ArrayList对象占用了99.80%的空间，继续展开到com.gbase.jdbc.ByteArrayRow类。
再看一下Leak Suspects
自动分析内存泄漏的原因，看到如下信息。
点开调用栈追踪。
至此已经能定位到是在读取gbase数据的时候，一次性读取的数据量太大了，导致datax的内存泄漏报出了OOM，也就是我们配置的fetchSize参数没有生效。
最终问题发现是在url拼接的时候没有把useCursorFetch=true带上，和mysql类似，gbase在读取的时候要使fetchSize参数生效需要拼接useCursorFetch=true。
