In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-02-24 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >
Share
Shulou(Shulou.com)06/01 Report--
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.
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.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.