会议网站定制,应届生出来做网站还是做报纸好,微信管理工具,做网站具备的条件文章目录 1、背景2、现象3、排查定位4、原因总结5、解决 1、背景
jdk8u45版本存在安全漏洞#xff0c;性能问题。需要升级到8u201
2、现象
升级到201版本后#xff0c;出现cpu.load过高
3、排查定位 使用压测工具压测时#xff0c;cpu.load过高问题必现#xff0c;确认… 文章目录 1、背景2、现象3、排查定位4、原因总结5、解决 1、背景
jdk8u45版本存在安全漏洞性能问题。需要升级到8u201
2、现象
升级到201版本后出现cpu.load过高
3、排查定位 使用压测工具压测时cpu.load过高问题必现确认是非偶发问题 使用Top命令查找占用cpu高的进程id 使用strace命令跟踪到此进程id产生的系统调用情况 (strace -p $(ps -ef | grep HetaspaceSize | awk ‘NR1 {print $2}’) -f -c)10发现syscall指标下有大量的mmap、mumap方法调用 使用Gdb命令查看代堆栈的信息发现JVM中 ActiveProcessorCount()函数调用了mmap 手动配置-XX:ActiveProcessorCount8配置此参数后发现占用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过高
