jvm代码逆优化导致的cpu升高

发布时间:2024年01月19日

背景

我们场景中会有使用ES来进行全文搜索的应用,既有往ES大量写数据的任务,也有直接构造查询条件从ES进行数据查询,但是偶尔ES会表现出system cpu负载很高的现象,而当把对应堆栈打印出来的时候,占用的cpu大头的是代码的逆优化的jvm方法,本文记录下运维查找的问题结果和原因

jvm代码逆优化导致的cpu飙升

jvm正常执行代码时,如果对应代码已经被执行多次,或者if else分支的某个条件一直满足,他就会把这些hotcode或者hot 的分支代码变异成本地机器码,下次执行时直接就是执行机器码就可以了,大大提高执行效率,然而这也会导致一些问题: 比如机器码中只包含了if某个分支的code,但是此时实际上方法的参数变了,实际上应该要执行到else分支,这种情况下,jvm不得不放弃掉这些机器代码,重新开始编译执行,这种极端情况下会导致很大的性能损耗,导致cpu负载升高,本次运维对ES的cpu升高问题的排除原因就是如此,ES中的很多方法逆优化导致的性能下降,进而导致cpu飙升,目前只有临时的解决方案:

-XX:ReservedCodeCacheSize=1G
-XX:PerMethodRecompilationCutoff=10000
-XX:PerBytecodeRecompilationCutoff=10000

这几个参数的目的是尽量减少jvm编译成机器code时去掉暂时不会进入的分支的code,也就是尽量保留所有的code到机器代码中,这样一旦需要进入不同的分支,机器代码中会存在对应分支的机器code,自然也就不需要反优化了.

参考文章:https://trino.io/blog/2021/10/06/jvm-issues-at-comcast.html
https://chriswhocodes.com/hotspot_options_openjdk21.html

文章来源:https://blog.csdn.net/lixia0417mul2/article/details/135706123
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。