Java程序在K8S容器部署CPU和Memory资源限制相关设置

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 背景在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.java

Step3: 不加参数运行

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.txt

Step5: 看看不同参数对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种方法可以进行:

  1. 建议升级到191以后的版本,然后根据cpu limit配置ActiveProcessorCount。
  2. 不升级jdk版本,直接设置跟ActiveProcessorCount参数相关的GC参数:比如ParallelGCThreads,CICompilerCount。如果是1.8.0_131以前的版本,可以用-Xms, -Xmx参数进行堆空间的大小分配,注意这两个参数只设置了分配给堆的大小,实际的memory limit应该比这个大。这种方案不是一个best practice,毕竟这样没有用到JVM自动适配的一些参数。最关键的,此种方法不能避免很多Java库根据availableProcessors()来做相应逻辑处理。

参考资料

  1. Assign Memory Resources to Containers and Pods
  2. Assign CPU Resources to Containers and Pods
  3. Kubernetes Demystified: Restrictions on Java Application Resources
  4. JVM 对 docker 容器 CPU 限制的兼容
  5. Java SE support for Docker CPU and memory limits
  6. 关于Jvm知识看这一篇就够了
相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
相关文章
|
18天前
|
监控 Kubernetes 网络协议
上云业务的k8s容器排障与思考
本文主要讲述了在完成业务上云后,面临因业务请求量激增导致的系统复杂故障和挑战。作者通过排查分析,发现了一个长时间处于“进行中”状态的异常任务,客户端(APP2)进程卡死,而服务端(APP3)进程正常结束。进一步分析发现,问题出在kube-proxy代理的会话超时机制,由于请求处理延迟,kube-proxy清理了会话记录,导致服务端回包异常,客户端无法识别,从而形成进程假死。 最后,作者强调了在成本控制背景下,通过分析流量增长原因、优化技术架构和调整运营策略来改善系统性能和稳定性的必要性。
311 5
上云业务的k8s容器排障与思考
|
1天前
|
jenkins Java Shell
蓝易云 - Java+Github+Jenkins部署
以上步骤完成后,每当你的Github仓库有新的提交时,Jenkins就会自动构建你的Java项目,并保存构建产物。
10 4
|
4天前
|
Java 应用服务中间件 Apache
安装和配置Apache Tomcat是部署Java Web应用程序的常见任务
安装和配置Apache Tomcat是部署Java Web应用程序的常见任务
20 7
|
2天前
|
安全 Java 网络安全
【认知革命】JAVA网络编程新视角:重新定义URL与URLConnection,让网络资源触手可及!
【6月更文挑战第22天】JAVA网络编程中,URL代表统一资源定位符,用于表示网络资源地址。通过`new URL(&quot;address&quot;)`创建URL对象,可解析和访问其组件。URLConnection是与URL建立连接的接口,用于定制HTTP请求,如设置GET/POST、超时及交换数据。
|
4天前
|
Java
死锁是线程间争夺资源造成的无限等待现象,Java示例展示了两个线程各自持有资源并等待对方释放,导致死锁。`
【6月更文挑战第20天】死锁是线程间争夺资源造成的无限等待现象,Java示例展示了两个线程各自持有资源并等待对方释放,导致死锁。`volatile`保证变量的可见性和部分原子性,确保多线程环境中值的即时更新。与`synchronized`相比,`volatile`作用于单个变量,不保证原子操作,同步范围有限,但开销较小。`synchronized`提供更全面的内存语义,保证原子性和可见性,适用于复杂并发控制。
13 3
|
4天前
|
Kubernetes 安全 Cloud Native
云上攻防-云原生篇&Kubernetes&K8s安全&API&Kubelet未授权访问&容器执行
云上攻防-云原生篇&Kubernetes&K8s安全&API&Kubelet未授权访问&容器执行
|
6天前
|
运维 Kubernetes Cloud Native
云原生时代的技术革命:Kubernetes与容器编排
【6月更文挑战第17天】在数字化转型的浪潮中,云原生技术正成为推动企业IT架构现代化的核心力量。本文将深入探讨Kubernetes作为云原生生态中的佼佼者,如何引领容器编排的技术革命,并分析其在现代应用部署、管理和扩展中的关键作用。通过实例和案例分析,我们将揭示Kubernetes如何助力企业实现更高效、灵活和可靠的云原生应用管理。
|
14天前
|
运维 Kubernetes 持续交付
Docker与Kubernetes:容器化技术的黄金搭档
【6月更文挑战第10天】Docker和Kubernetes是容器化技术的黄金组合,Docker提供轻量级、可移植的容器引擎,简化应用部署,而Kubernetes作为容器编排系统,实现自动化部署、扩展和管理,确保高可用性和可扩展性。两者的协作使得容器化应用更高效、可靠,共同推动软件开发和运维的创新。
|
18天前
|
运维 Kubernetes Java
Java一分钟之Kubernetes(K8s):容器编排深入浅出
【6月更文挑战第6天】Kubernetes是容器编排的主流工具,简化分布式系统运维。本文介绍了K8s核心概念:节点、Pod、服务、部署和副本集。讨论了资源不足、依赖服务未就绪等常见问题及其解决策略,并提供创建Deployment的代码示例。学习K8s能提升部署效率和运维灵活性。
119 5
|
21天前
|
Java 关系型数据库 MySQL
【JavaEE进阶】 Linux搭建Java部署环境
【JavaEE进阶】 Linux搭建Java部署环境

相关产品

  • 容器服务Kubernetes版