背景
近来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 发表
