标签：记录 新生代 回收 调优 Elasticsearch 垃圾 gc CMS 内存
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%以下。
标签：记录,新生代,回收,调优,Elasticsearch,垃圾,gc,CMS,内存 来源： https://www.cnblogs.com/winddogg/p/15814592.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。