排查elasticsearch的cpu居高不下，查询慢的问题

Posted 2023-05-02

参考技术A 近来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高、查询慢的问题也一并归类到该文。

tomcat占用cpu过高解决办法

在工作中经常遇到tomcat占用cpu居高不下，针对这种情况有以下处理办法进行排查。

 

jps --> 查看java的进程


top -Hp pid --> 根据jps得到的进程号(pid)，查看java进程的所有线程，并且可以看到所有线程占用CPU的情况，-H用于显示某个进程的所有线程。


printf "%x
" 9733 -->将第2步查到占用较高CPU的线程号转换为16进制，以便于jstack查看


jstack pid | grep 2605 --> 2605为第3步9733转换为16进制后的数字，因为jstack显示的线程号是以16进制表示的！
jstack的作用是显示正在运行的所有java线程情况，jstack pid | grep 2605的意思只显示某个java线程的运行信息。通过这种方法，可以将此线程正在运行的方法显示出来，将此方法交给开发即可