背景
近來es查詢很慢,kibana的discover界面偶爾還會因為查詢請求超時而無法顯示數據。/_cat/indices?v
等對es的查詢也慢的出奇,需要1、2分鐘才返回結果。
排查
top命令看了es的java進程,發現cpu一直很高,130%左右,一直沒有下降過。查看es的日志,發現gc.log中幾乎每秒都要觸發一次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:這次是小坑,后面可能還有很多大坑需要踩。后續有cpu高、查詢慢的問題也一并歸類到該文。
- 本文固定鏈接: http://zoufeng.net/2018/07/16/cpu-of-elasticsearch-high-search-slow/
- 轉載請注明: foam 2018年07月16日于 foam 發表