Shulou(Shulou.com)06/01 Report--

JFR orientation is how to solve the problem of high CPU Load caused by SSL. I believe that many inexperienced people are at a loss about this. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Problem scenario

At some point, the CPU load of an instance of a microservice suddenly soars.

Problem positioning

As a result of the establishment of a lot of database links, guess that the database is relatively slow, look at the database of this period of time SQL statistics, found that the database is not slow.

Among them, the hot SQL of micro-service during this period of time, the execution is not slow. So what's the problem? It may be due to GC, safepoint, or long lock acquisition time (see Java Monitoring JFR solution). Let's dump the JFR and check the safepoint,GC and Monitor Blocked-related events.

First check the GC and find that they are all Young GC, and the GC pause time is also acceptable.

Then there is safepoint, although safepoint has been collected, but the pause time is not very long.

Finally, I looked at Java Monitor Block and found that there was a lot of waiting for locks.

The stack shows that it is blocked on: void sun.security.provider.SecureRandom.engineNextBytes (byte []), which is a classic problem, Java Random, reference code: NativePRNG

/ / name of the * System* property, takes precedence over PROP_RNDSOURCEprivate static final String PROP_EGD = "java.security.egd"; / / name of the * Security* propertyprivate 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"

Two random number seed generation methods are involved, one is "file:/dev/random" and the other is "file:/dev/urandom", which is specified by setting the system property java.security.egd. The default is "file:/dev/random".

When the entropy pool is insufficient, the default "file:/dev/random" will block, "file:/dev/urandom" will not, continue to use. "file:/dev/urandom" is sufficient for us, so set the system properties through-Djava.security.egd=file:/dev/./urandom and use urandom to reduce blocking.

After reading the above, have you mastered how to solve the problem of JFR positioning that CPU Load is high because of SSL? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.