在Kubernetes上對Java的微調研究 - brunoborges

在Kubernetes上對Java的三個方面的研究：

• - ActiveProcessorCount
• - 預設GC
• - 預設Heap Sizing

ActiveProcessorCount 當前匹配cpu_quota: up to 1000m, 1 proc. 1001-2000m, 2 procs, 等等

這聽起來很合理，但正如我們所瞭解的，CFS 控制器不限制 CPU 數量，只限制 CPU 時間。多個本地執行緒可以並行執行，直到達到 cpu_quota配額。

僅在 JVM 看到超過 1792 MB 的可用記憶體和 2 個可用處理器（k8s 中為 2000m+）時預設選擇 G1GC，否則它會選擇 SerialGC。

因此，這就是為什麼這麼多開發人員在受限制的容器中強制使用 -XX:+UseG1GC。

堆大小預設為可用記憶體的 1/4。許多開發人員使用 Xmx 將堆設定為可用 RAM 的 50% 到 80% 之間。

理想情況下，開發人員應該使用 -XX:MaxRAMPercentage，以便 JVM 與 k8s 中的容器一起擴充套件。

我們想了解為什麼 JVM 在為更多可用處理器調整自身大小時表現不同，即使它受到 CPU 節流。也許與執行緒排程有關？

此外，這將如何影響 G1GC，以及更多堆記憶體是否可以減少 CPU 節流時間。

顯然，開發人員在沒有考慮 JVM 的工作方式以及並行、多執行緒工作（例如 JIT 編譯器和 GC）的需要情況下，無法為 Kubernetes 正確調整 Java 工作負載的大小，

1000m 似乎不是一個好的最小值，但它很常見。

在我看來，使用更多副本解決 CPU 節流也是一種常見的解決方法，但不是理想的解決方案。

我們的假設仍然是，對於某些工作負載，減少副本並增加 cpu 限制，可能節省成本，可能會提供更好的效能。

但是又發現 JVM 可能在較低的 cpu 限制下表現得更好，只要它為多個處理器調整自己的大小，至少在今天是一個有趣的實驗。