Tomcat 8), tomcat

Tomcat 8 entropy pool congestion slowdown (conversion), tomcat
Explanation of Tomcat 8 entropy pool blocking slowdown Author: chszs, reprinted need to be noted. Blog homepage: http://blog.csdn.net/chszs

Tomcat 8 is very slow to start and there are no errors in the log. The following information is displayed in the log:

Log4j:[2015-10-29 15:47:11]  INFO ReadProperty:172 - Loading properties file from class path resource [resources/jdbc.properties]Log4j:[2015-10-29 15:47:11]  INFO ReadProperty:172 - Loading properties file from class path resource [resources/common.properties]29-Oct-2015 15:52:53.587 INFO [localhost-startStop-1] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [342,445] milliseconds.

Cause

Tomcat 7/8 uses the org. apache. catalina. util. SessionIdGeneratorBase. createSecureRandom class to generate a SecureRandom instance as the session ID. It takes 342 seconds, that is, 6 minutes.

The SHA1PRNG algorithm is a pseudo-random number generator that is implemented based on the SHA-1 algorithm and has strong confidentiality.

In SHA1PRNG, there is a seed generator that performs various operations according to the configuration.

1) if Java. security. egd attribute or securerandom. the source attribute specifies "file:/dev/random" or "file:/dev/urandom". Then, the JVM uses the NativeSeedGenerator, which calls super () method, that is, call SeedGenerator. the URLSeedGenerator (/dev/random) method is initialized.

2) If the java. security. egd attribute or securerandom. source attribute specifies other existing URLs, The SeedGenerator. URLSeedGenerator (URL) method will be called for initialization.

This is why we set "file: // dev/urandom" or "file: // dev/random.

In this implementation, the generator evaluates the number of noises in the entropy pool. Random numbers are created from the entropy pool. During read operations, the/dev/random Device returns only random bytes of noise in the entropy pool. /Dev/random is ideal for scenarios that require high quality randomness, such as one-time payment or key generation.

When the entropy pool is empty, read operations from/dev/random will be blocked until the entropy pool collects sufficient environmental noise data. The purpose of this is to become a password-safe pseudo-random number generator, and the entropy pool should have as much output as possible. This must be done in scenarios where high-quality encryption keys are generated or long-term protection is required.

So what is environmental noise?

The random number generator will store the environmental noise data from the drive and other sources of the mobile phone in the entropy pool. The generator evaluates the number of noise data in the entropy pool. When the entropy pool is empty, it takes time to collect the noise data. This means that Tomcat will be blocked for a long time when the entropy pool is used in the production environment.

Solution

There are two solutions:

1) solve the problem in the Tomcat Environment

You can configure JRE to use non-blocking Entropy Source.

Add this line to catalina. sh:-Djava. security. egd = file:/dev/./urandom.

After Tomcat is started, the whole startup time is reduced to Server startup in 2912 ms.

2) solve the problem in the JVM Environment

Open the $ JAVA_PATH/jre/lib/security/java. security File and find the following content:

securerandom.source=file:/dev/urandom

Replace

securerandom.source=file:/dev/./urandom