1.背景
部署Elasticsearch服务，主要提供记录用户登录日志、访问日志，统计，查询等功能。
遇到的问题为：
- 平稳运行时CPU使用率为20%左右，当批量更新定时任务执行时，
CPU使用率激增到60%左右，最高值到达90%，服务器监控系统开始报警。
- Elasticsearch长时间运行，内存占用率大幅提高，严重影响功能使用，需要在内存占用较大时重启ES服务。
2.定位CPU使用率高问题以及解决办法
Elasticsearch是基于java开发的，先查看elasticsearch进程的运行情况，然后查看jvm相关参数。生产环境问题已解决（部分问题暂时无法提供截图说明）
1.定位到具体问题
使用jstat -gcutil pid 1000 命令查看垃圾回收情况
可知每两秒进行一次minor GC,定位问题为频繁的minor GC 引起的cpu使用率居高不下。
2.查看垃圾回收器和内存分配情况
1.确定垃圾回收器的使用
生产环境使用jdk版本为jdk11,jvm.options文件中相关参数表明
在jdk8-13默认使用的垃圾回收算法为CMS,因为CMS为老年代垃圾收集器，默认与之配合使用的新生代垃圾回收器为ParNew。
使用jps命令找到ES运行的进程id
使用jinfo命令 查看jvm的相关参数，确认使用的垃圾回收器为ParNew+CMS。
2.查看heap大小分配情况
服务器内存为16g,根据官方推荐heap大小配置不宜超过8g
jvm.options配置参数为
-Xmx7g
-Xms7g
没有显示声明新生代的大小，CMS垃圾回收器新生代默认大小为：
max_heap/(NewRatio+1)和ScaleForWordSize(young_gen_per_worker * parallel_gc_threads) 中最小的值。
max_heap/(NewRatio+1) 即最大堆内存/(2+1) （未显式设置参数NewRatio 则默认为2) 7*1024/3=2389.33M
ScaleForWordSize(young_gen_per_worker * parallel_gc_threads) 计算公式为 young_gen_per_worker * parallel_gc_threads * 13/10
young_gen_per_worker 的值x86机器为64M，parallel_gc_threads简单的理解为cpu核数8 64*8*13/10=665M
即最后的新生代大小为665M
使用jstat -gc 查看内存分配情况 新生代为665M，
默认参数-XX:SurvivorRatio=8 即Eden:S0:S1=8:1:1 可知Eden内存大小为532M
可知新生代内存设置太小，Eden区满了之后会进行频繁的minor GC导致Cpu占用率提高
3.解决办法
1.显式设置参数-Xmn 由于老年代占用比例较小，且在minor GC 过程中晋升到老年代的对象较少，所以可以提高新生代的内存占比设置为-Xmn4g
2.改用G1垃圾回收器，可在垃圾回收过程中根据使用情况动态改变新生代的大小
3.定位Elasticsearch长时间运行，内存占用率高问题以及解决办法
CMS会在垃圾回收过程中产生内存碎片，不利于程序的长时间运行。
而G1在运行期间不会产生内存碎片，有利于程序长时间运行。
综上所述，从两个方面来看以及生产环境的试运行情况来看，选择修改垃圾回收器为G1的解决方案。
总结，修改垃圾回收器为G1后，平稳期cpu使用率稳定在5%以下。