jdk8u201版本cpu.load过高问题的排查和解决

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高
    1
    2
    3
    4

• 开始排查业务代码中，哪里会用到查询cpu核数的逻辑

  • 发现出现load过高的服务，基本都是QPS较高的业务，对外提供QPS较高的rpc接口(内部大量 CompletableFuture异步调用下游不同服务获取不同数据，并最后CompletableFuture.join()等待异步结果返回，再组装所有数据返回)

  • 发现join()内部会调用waitingGet获取cpu核数

    Runtine.getRuntime().availableProcssors()
    1

• 至此问题彻底定位。

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过高