JFR 定位因为 SSL 导致 CPU Load 飚高的问题

原创
2020/09/27 19:45
阅读数 11

问题场景

在某一时刻,某个微服务的某个实例 CPU 负载突然飚高:

image

同时建立了很多数据库链接: image

其他实例没有这个现象。

问题定位

由于建立了很多数据库链接,猜想可能是数据库比较慢,查看数据库这段时间的 SQL 统计,发现数据库并不慢:

image

其中这个微服务这段时间的热点 SQL,执行并不慢。那么问题出在了哪里呢?可能是由于 GC,可能是由于 safepoint,还有可能是获取锁时间过长(参考:Java 监控 JFR全解),我们 dump 一下 JFR 并查看其中的 safepoint,GC 以及 Monitor Blocked 相关事件。

首先查看GC,发现都是 Young GC, GC 暂停时间也可以接受。

image

然后是 safepoint,虽然有采集到 safepoint,但是暂停时间也没有很长。

image

最后查看 Java Monitor Block,发现有很多很长时间的锁等待:

image

堆栈显示,阻塞在:void sun.security.provider.SecureRandom.engineNextBytes(byte[])上面,这就是一个经典的问题,Java Random,参考代码:NativePRNG

// name of the *System* property, takes precedence over PROP_RNDSOURCE
private static final String PROP_EGD = "java.security.egd";
// name of the *Security* property
private static final String PROP_RNDSOURCE = "securerandom.source";

private static final boolean useLegacyDSA =
    Boolean.parseBoolean(GetPropertyAction.privilegedGetProperty
        ("jdk.security.legacyDSAKeyPairGenerator"));

static final String URL_DEV_RANDOM = "file:/dev/random";
static final String URL_DEV_URANDOM = "file:/dev/urandom";

涉及到两种随机数 seed 生成方式,一种是"file:/dev/random",另一种是"file:/dev/urandom",通过设置系统属性java.security.egd指定,默认是"file:/dev/random"

两种 Random 原理与解决

在 Linux 4.8 之前:

image

在 Linux 4.8 之后:

image

在熵池不够用的时候,默认的"file:/dev/random"会阻塞,"file:/dev/urandom"不会,继续用。对于我们来说,"file:/dev/urandom"够用,所以通过-Djava.security.egd=file:/dev/./urandom设置系统属性,使用 urandom 来减少阻塞。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部