背景
近來es查詢很慢，kibana的discover界面偶爾還會因為查詢請求超時而無法顯示數(shù)據(jù)。/_cat/indices?v 等對es的查詢也慢的出奇，需要1、2分鐘才返回結果。
排查
top命令看了es的java進程，發(fā)現(xiàn)cpu一直很高，130%左右，一直沒有下降過。查看es的日志，發(fā)現(xiàn)gc.log中幾乎每秒都要觸發(fā)一次GC Full GC (Allocation Failure)。內存不夠用，又沒有內存可回收，所以GC也不斷。怪不得CPU這么高，大部分時間都用在gc上面了。
處理
調整es可使用的內存大小。編輯config/jvm.options，調整了Xms和Xmx的大小，由原來默認的1g調整為10g。（官方建議這個值不要超過物理內存的50%，也不要超過32G。詳見官網說明）接著重啟es就好了。觀察cpu，雖然偶爾也會彪上130%，但總體來說正常了，查詢也變得很快。
ps：es重啟后，需要觀察logstash是否退出了。如果退出，需要重新把logstash拉起來。
pss：這次是小坑，后面可能還有很多大坑需要踩。后續(xù)有cpu高、查詢慢的問題也一并歸類到該文。
- 本文固定鏈接: http://zoufeng.net/2018/07/16/cpu-of-elasticsearch-high-search-slow/
- 轉載請注明: foam 2018年07月16日于 foam 發(fā)表
