Jvm parameter adjustment in k8s

Jvm parameter adjustment in k8s

As a code farmer whose jvm parameters have always been manually adjusted, he has no sense of automatic adjustment. Parameters such as the number of gc threads are adjusted manually.
Later found that the advantage of this is that various parameters can be controlled, but the disadvantage is that it is too cumbersome to adjust once. Each process is adjusted in this way, and the workload will become particularly large.
Therefore, the use of default parameters has a huge effect in starting business in the early stage.

k8s problem

When the java process runs on the physical machine, it is our common method, and nothing is set, then xmx is one-fourth of the physical machine process by default. This problem is not big, there will be some small accidents when running in k8s. The default number of gc threads is also related to the number of cpu cores.

• It
  is not uncommon to use too many gc threads. The total number of physical machines may have 98 cores, but the pod only allocates 4 cores. Before java10, the number of cores available to him is the core number of the physical machine. There are a lot of gc threads started by default.
• xmx is too small by default.
  After the jvm is started, there is 4g of memory space, but xmx is actually only 1g. The rest need to be forced to specify xmx to use the space.

Problem solving

• Upgrading to jdk10
  has the parameter -XX: UseContainerSupport in jdk10 to solve all the above problems. k8s gives 4 cores and 3g of memory, then the maximum xmx is 3g, and the number of cores available for cpu is 4 cores.
• If you can’t upgrade to 10
  above jdk8 191, cpu can use the parameter ActiveProcessorCount to control the number of cores available for cpu. Use RAMPercentage and other parameters to control the default ratio of xmx.
• If it is the following version of jdk8 191, you
  can only choose to manually control each parameter. Among them, in a certain version of 8, you can use UseCGroupMemoryLimitForHeap to turn on the perception of resource settings, and use MaxRAMFraction to control memory. The drawback of MaxRAMFraction is that it can only set positive numbers, such as 1, 2, 3, which represent 1, 1/2, and 1/3 respectively. The intensity of this control is relatively large. If RAMPercentage series is available, this parameter is not necessary. RAMPercentage can be set as a percentage, and the controlled resources will be greater.

summary

Deploying resources in k8s, all parameter control is the best, so it takes more time to make the program run more stably. Compared to the simplicity of default parameters, it is not worthwhile to invest experience in parameter configuration in the early stages of development. If you have a development environment, you can try to use the new jdk. The support for k8s is better and more convenient. After tuning and verification, the tuned parameters are finally used for the program
in the pod . The solution in different jdk is different. This is a consideration of stability and simplicity. The stability of the new version of jdk will be weaker than the version that has been running for a long time. Therefore, upgrading jdk is also a matter to consider, but during testing, the program runs unstable and only verifies the function. This is a relatively good choice.
How to choose in the lower version, I generally recommend the highest version of the lower version, such as jdk8, choose the highest version of 8. When the function is stable, the latter version usually fixes the previous bug. Therefore, the higher the version changes little, and the stability is guaranteed.