问题现象
- 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 中节点通信大小限制的调整
