1、背景
jdk8u45版本存在安全漏洞,性能问题。需要升级到8u201
2、现象
升级到201版本后,出现cpu.load过高
3、排查定位
-
使用压测工具压测时,cpu.load过高问题必现,确认是非偶发问题
-
使用Top命令查找占用cpu高的进程id
-
使用strace命令跟踪到此进程id产生的系统调用情况
- (strace -p $(ps -ef | grep HetaspaceSize | awk ‘NR==1 {print $2}’) -f -c)10
- 发现syscall指标下有大量的mmap、mumap方法调用
-
使用Gdb命令查看代堆栈的信息,发现JVM中 ActiveProcessorCount()函数调用了mmap
-
手动配置-XX:ActiveProcessorCount=8(配置此参数后,发现占用CPU高的进程消失同时mmap和mumap的调用量也恢复正常
-
故查看jdk 201版本源码中哪儿使用了ActiveProcessorCount参数。发现:
-
201为了支持容器功能,对cpu核数的取数逻辑进行了改动。新逻辑为
if(ActiveProcessorCount > 0){// 默认不会配置这个参数 return ActiveProcessorCount; } // 否则调用fgets函数库,此函数内部使用mmap分配buffer,高频的调用时会导致cpu.load高
-
-
开始排查业务代码中,哪里会用到查询cpu核数的逻辑
-
发现出现load过高的服务,基本都是QPS较高的业务,对外提供QPS较高的rpc接口(内部大量 CompletableFuture异步调用下游不同服务获取不同数据,并最后CompletableFuture.join()等待异步结果返回,再组装所有数据返回)
-
发现join()内部会调用waitingGet获取cpu核数
Runtine.getRuntime().availableProcssors()
-
-
至此问题彻底定位。
4、原因总结
- 升级版本到201的服务中,有大量使用CompletableFuture.join()
- join中waitingGet方法会调用Runtine,getRuntime().availableProcessors()获取cpu核数
- 当JVM未配置ActiveProcessorCount参数,201版本会调用fgets()库函数。
- 其内部使用mmap申请buffer,当频繁的join -> 频繁的获取cpu核数->频繁的调用mmap和mumap时,会导致cpu.load过高
5、解决
JVM参数指定 -XX:ActivtProcessorCount -n (这里的n为机器的核数)
- 这样当join() -> 获取cpu核数 -> XX:ActivtProcessorCount >0,则直接返回XX:ActivtProcessorCount = n的值
- j就不会再调用fgets函数库,自然不会调用mmap分配buffer,从而避免了高频的调用导致cpu.load过高