Example Analysis of slow start-up troubleshooting of springboot Application based on K8s deployment pod

The springboot application is based on the example analysis of slow start-up of pod in K8s deployment. Many novices are not very clear about this. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

When springboot applications are deployed in a k8s cluster, the application starts slowly, as shown in the figure:

If you view logs based on kubelet log-f pod, log printing is also slow

After debugging changes:

The devices / dev/random and / dev/urandom on the Linux system are different.

/ dev/random devices do not provide pseudo-random data, but random data based on real random factors in the environment (that is, background noise as an entropy source).

So, / dev/random is not like the device / dev/urandom. The latter is a pseudo-random data generator, which can quickly generate the required amount of data according to the request. How much content / dev/random can generate is determined by the noise in the environment. / dev/random can only wait when there is insufficient data.

Therefore, when the content is insufficient, / dev/random blocks the read operation until enough random data is collected. This is the reason for the difference in the test results. / dev/random blocks the second read for nearly a minute.

Therefore, for those who use / dev/random devices, it is possible to block. When blocked, the upper application may show slow startup or abnormal execution time. Because the / dev/random behavior is related to the environmental background, the behavior is random. Therefore, it also leads to the random performance of the problems caused by the upper application, which is not easy to troubleshoot.

For example, in the Java community, problems caused by / dev/random devices were reported by bug as early as the jdk-1.4 version. However, there are still customers who do not know the cause and solution of similar problems.

The solution is simply that the / dev/random device must be used unless there is a clear reason. Otherwise, use the / dev/urandom device.

For jdk, what is needed is to change the securerandom.source=file:/dev/random in the $JAVA_HOME/jre/lib/security/java.security in the configuration file to securerandom.source=file:/dev/urandom

Investigation suggestion

For Java programs that start slowly or the process takes time abnormally, please give priority to troubleshooting if it is a / dev/random problem. The steps are as follows

Confirm that the device / dev/random is being used. Just check the configuration for $JAVA_HOME/jre/lib/security/java.security.

If so, change the configuration.

Restart the Java program to confirm that the problem is resolved.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.