問題現(xiàn)象
- zk 定期oom攀痊，連接以及watch數(shù)過多
- druid segment一直處于恢復(fù)中
- druid data節(jié)點挨個掛
- 掛的同時會報一個oom几颜，不是普通的oom
關(guān)于oom
- 堆內(nèi)存oom
- 棧oom
- out of memory
gc時間過長褒墨，導(dǎo)致out of memory
out of memory error革娄，there is insufficient memory for the java runtime Environment to continue
此次 druid data節(jié)點的現(xiàn)象類似
- 反推一下可以發(fā)現(xiàn)捅膘，segment 不停的做著恢復(fù)翘地，但是回復(fù)到一定時候又掛了申尤，導(dǎo)致越來越多的segment同時掛掉癌幕，那么就會短時間內(nèi)有很多的zk path產(chǎn)生，導(dǎo)致zk oom
問題的關(guān)鍵
關(guān)鍵問題是找到昧穿，druid data節(jié)點oom的根本原有并解決
了解其部分邏輯之后勺远，懷疑并發(fā)操作過多，多線程24個同時去讀取segment时鸵，
但是因為druid 使用了 java mmap技術(shù)0拷貝胶逢，所以理論上來說是不太可能的
另外參考了druid 官方的一些部署建議配置，存儲和計算其實不太一樣
存儲對于機器性能的配置是有一些要求的饰潜，比如 map相關(guān)參數(shù)初坠，vm.map.max
關(guān)于mmap
ulimit -a 查看機器的一些限制
mmap 的底層原理，bytebuff 復(fù)制彭雾，讀寫流程如何碟刺？
寫時是否實時刷新還是定時刷新，
page cache 是啥薯酝？
cat /proc/$(pidof java)/smaps|grep a.txt -A 10 -B 10
查看進程下的 page 半沽？
mmap的一些限制，vm.max_count
druid的建議
- 應(yīng)增加觸及大小的時候拋出調(diào)整建議
- zk 中節(jié)點通信大小限制的調(diào)整
