druid导致zk oom的问题

问题现象

• zk 定期oom，连接以及watch数过多
• druid segment一直处于恢复中
• druid data节点挨个挂
• 挂的同时会报一个oom，不是普通的oom

关于oom

• 堆内存oom
• 栈oom
• out of memory
  gc时间过长，导致out of memory
  out of memory error，there is insufficient memory for the java runtime Environment to continue

此次 druid data节点的现象类似

• 反推一下可以发现，segment 不停的做着恢复，但是回复到一定时候又挂了，导致越来越多的segment同时挂掉，那么就会短时间内有很多的zk path产生，导致zk oom

问题的关键

关键问题是找到，druid data节点oom的根本原有并解决
了解其部分逻辑之后，怀疑并发操作过多，多线程24个同时去读取segment，

但是因为druid 使用了 java mmap技术0拷贝，所以理论上来说是不太可能的

另外参考了druid 官方的一些部署建议配置，存储和计算其实不太一样

存储对于机器性能的配置是有一些要求的，比如 map相关参数，vm.map.max

关于mmap

ulimit -a 查看机器的一些限制
mmap 的底层原理，bytebuff 复制，读写流程如何？
写时是否实时刷新还是定时刷新，
page cache 是啥？
cat /proc/$(pidof java)/smaps|grep a.txt -A 10 -B 10
查看进程下的 page ？
mmap的一些限制，vm.max_count

druid的建议

• 应增加触及大小的时候抛出调整建议
• zk 中节点通信大小限制的调整