elasticsearch服务器CPU100%分析
1、通过top命令查询占用CPU高的进程ID
2、查询是哪些线程占用比较高
top -Hp 28354
- H代表显示线程信息
- p用来指定进程id
发现线程31342、28478等占用比较多的CPU资源
3、将十进制pid转换为十六进制的pid
printf “0x%x” 28478
4、查询具体的线程信息
jstack -l 28354 | grep 6f3e -A 20
这里我们基本上可以确定，当前系统缓慢的原因主要是垃圾回收过于频繁，导致 GC 停顿时间较长。
5、我们通过如下命令可以查看 GC 的情况
jstat -gcutil 28354 1000 10
28354为进程ID，1000代表每隔1000毫秒检查一次, 10代表检查10次, 10也可以省略, 表示不限次数
可以看到，这里 FGC 指的是 Full GC 数量，这里高达 31115，而且还在不断增长。从而进一步证实了是由于内存溢出导致的系统缓慢。
6、通过jmap输出内存使用信息
jmap -dump:live,format=b,file=28354.hprof 28354
28354为进程ID
使用hprof二进制形式,输出jvm的heap内容到文件
live子选项是可选的，假如指定live选项,那么只输出活的对象到文件
7、通过MAT分析内存dump
MAT下载地址：http://www.eclipse.org/mat/
elasticsearch默认的JVM配置中，Xms、Xmx都为1G，不太够用，我们修改JVM配置，将Xms、Xmx修改为2G
vim /etc/elasticsearch/jvm.options
-Xms2g
-Xmx2g
重启elasticsearch服务后，CPU使用率降了下来。
注意：本文侧重在怎样分析JAVA程序CPU%的问题，而不是对elasticsearch服务的分析、优化
