https://developer.aliyun.com/article/700701
简介： 背景在k8s docker环境中执行Java程序，因为我们设置了cpu，memory的limit，所以Java程序执行时JVM的参数没有跟我们设置的参数关联，导致JVM感知到的cpu和memory是我们k8s的work node上的cpu和memory大小。
背景
在k8s docker环境中执行Java程序，因为我们设置了cpu，memory的limit，所以Java程序执行时JVM的参数没有跟我们设置的参数关联，导致JVM感知到的cpu和memory是我们k8s的work node上的cpu和memory大小。这样造成的问题是：当容器中Java程序使用内存超过memory limit时，直接造成Out of Memory错误，从而引起容器重启。JVM很多参数也是很智能的，启动时内存的分配也会根据cpu和memory进行调整，比如GC相关的参数就是动态调整的。如果容器感知到的cpu核数不对，那么对程序的性能也会造成很大的影响。
内存
Java对内存的使用有几个参数可以配置。以前的版本可以用-Xms, -Xmx来分别设置初始化Java堆大小和最大的Java堆大小。但因为Java堆大小并不等于所有可用的内存大小，所以在设置memory limit的时候会加一个值。这样避免Java使用的内存超过分配给容器的最大内存限制。这个增加的值需要一定的经验和测试来获取。
JVM后来提供了UseCGroupMemoryLimitForHeap参数来让JVM自动根据我们提供的内存限制来分配堆的大小。这样也就避免了我们人为去确定应该给堆多大的空间。只要经过测试，确定这个Java程序占用的总共空间就行了。使用方法是在java运行后面加上参数：java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap ⋯
CPU
配了上面的参数，我们还没有完全解决问题。因为JVM GC相关的参数跟CPU处理器核相关联的，可使用的CPU核数越多，分配给GC的线程资源也越多。如果我们不设置正确的CPU核数给容器，那么它看到的就是整个k8s worker node的CPU个数，比如我们限制容器可使用2core，但worker node有32core。那么这个容器会给GC分配很多的线程资源，从而严重影响正常Java线程的运行。
CPU个数对JVM GC的影响
JVM提供了ActiveProcessorCount参数来设置这个值。但这个参数只在java 1.8.0_191以后版本才支持。下面我在笔记本上做了测试（total 8 cores），看看这个参数如何影响GC的参数。
Step1: 写一个hello wold程序。
root@kyle:~# cat Hello.java
public class Hello{
public static void main(String[] args){
System.out.println("hello world");
}Step2: 编译
root@kyle:~# javac Hello.javaStep3: 不加参数运行
root@kyle:~# java -XX:+PrintFlagsFinal Hello > init.txt
[Global flags]
intx ActiveProcessorCount = -1 {product}
uintx AdaptiveSizeDecrementScaleFactor = 4 {product}
uintx AdaptiveSizeMajorGCDecayTimeScale = 10 {product}
uintx AdaptiveSizePausePolicy = 0 {product}
uintx AdaptiveSizePolicyCollectionCostMargin = 50 {product}
…Step4: 加不同参数值运行
root@kyle:~# java -XX:ActiveProcessorCount=1 -XX:+PrintFlagsFinal Hello > p1.txt
root@kyle:~# java -XX:ActiveProcessorCount=2 -XX:+PrintFlagsFinal Hello > p2.txt
root@kyle:~# java -XX:ActiveProcessorCount=4 -XX:+PrintFlagsFinal Hello > p4.txt
root@kyle:~# java -XX:ActiveProcessorCount=8 -XX:+PrintFlagsFinal Hello > p8.txtStep5: 看看不同参数对GC的影响：
1个处理器跟2个处理器的比较：
root@kyle:~# diff p1.txt p2.txt
2c2
< intx ActiveProcessorCount := 1 {product}
---
> intx ActiveProcessorCount := 2 {product}
304c304
< uintx MarkSweepDeadRatio = 5 {product}
---
> uintx MarkSweepDeadRatio = 1 {product}
311c311
< uintx MaxHeapFreeRatio = 70 {manageable}
---
> uintx MaxHeapFreeRatio = 100 {manageable}
335,336c335,336
< uintx MinHeapDeltaBytes := 196608 {product}
< uintx MinHeapFreeRatio = 40 {manageable}
---
> uintx MinHeapDeltaBytes := 524288 {product}
> uintx MinHeapFreeRatio = 0 {manageable}
388c388
< uintx ParallelGCThreads = 0 {product}
---
> uintx ParallelGCThreads = 2 {product}
682,683c682,683
< bool UseParallelGC = false {product}
< bool UseParallelOldGC = false {product}
---
> bool UseParallelGC := true {product}
> bool UseParallelOldGC = true {product}
2个处理器跟4个处理器的比较：
root@kyle:~# diff p2.txt p4.txt
2c2
< intx ActiveProcessorCount := 2 {product}
---
> intx ActiveProcessorCount := 4 {product}
59c59
< intx CICompilerCount := 2 {product}
---
> intx CICompilerCount := 3 {product}
388c388
< uintx ParallelGCThreads = 2 {product}
---
> uintx ParallelGCThreads = 4 {product}4个处理器跟8个处理器的比较：
root@kyle:~# diff p4.txt p8.txt
2c2
< intx ActiveProcessorCount := 4 {product}
---
> intx ActiveProcessorCount := 8 {product}
59c59
< intx CICompilerCount := 3 {product}
---
> intx CICompilerCount := 4 {product}
388c388
< uintx ParallelGCThreads = 4 {product}
---
> uintx ParallelGCThreads = 8 {product}不加参数跟8个处理器的比较：
root@kyle:~# diff init.txt p8.txt
2c2
< intx ActiveProcessorCount = -1 {product}
---
> intx ActiveProcessorCount := 8 {product}从上面比较可以看出，不设这个参数跟设置最大参数（当前系统是8core）是一样的。2，4，8核设置只影响ParallelGCThreads, CICompilerCount。但如果只用1核的话，UseParallelGC，UseParallelOldGC都变为false，同时也会影响其它几个参数。见上面diff p1.txt p2.txt比较结果。
CPU个数对Java程序的影响
CPU个数的设置除了对JVM GC性能产生影响外，对Java的工作线程也会产生影响。以下的代码常用于Java库，它会根据CPU的个数产生工作线程。如果没有正确设置docker中的参数，对实际的程序性能会产生很大的影响。
Runtime.getRuntime().availableProcessors()以下代码摘自aliyun-log-java-producer库，是根据可用处理器来产生相应个数的IO线程来发送loghub数据。
# ProducerConfig.java:
public class ProducerConfig {
public static final int DEFAULT_IO_THREAD_COUNT =
Math.max(Runtime.getRuntime().availableProcessors(), 1);OpenJDK版本
我们运行以下命令检查JDK的版本。openjdk version "1.8.0_131"以后支持UseCGroupMemoryLimitForHeap参数，"1.8.0_191"以后才支持ActiveProcessorCount这个参数。
root@kyle:~# java -version
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-2ubuntu0.16.04.1-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)改进方案
如果我们使用的JDK版本支持这2个参数，那么我们只需要在运行Java程序时把这UseCGroupMemoryLimitForHeap参数加上，同时再给ActiveProcessorCount参数赋值实际分配给容器的cpu limit就可以了。如果目前的JDK版本低于1.8.0_191，即不支持ActiveProcessorCount，针对这个情况，有2种方法可以进行：
- 建议升级到191以后的版本，然后根据cpu limit配置ActiveProcessorCount。
- 不升级jdk版本，直接设置跟ActiveProcessorCount参数相关的GC参数：比如ParallelGCThreads，CICompilerCount。如果是1.8.0_131以前的版本，可以用-Xms, -Xmx参数进行堆空间的大小分配，注意这两个参数只设置了分配给堆的大小，实际的memory limit应该比这个大。这种方案不是一个best practice，毕竟这样没有用到JVM自动适配的一些参数。最关键的，此种方法不能避免很多Java库根据availableProcessors()来做相应逻辑处理。
参考资料
- Assign Memory Resources to Containers and Pods
- Assign CPU Resources to Containers and Pods
- Kubernetes Demystified: Restrictions on Java Application Resources
- JVM 对 docker 容器 CPU 限制的兼容
- Java SE support for Docker CPU and memory limits
- 关于Jvm知识看这一篇就够了