查看原文
其他

减少 Docker 和 Kubernetes 中的 JVM 内存占用

ImportNew 2022-04-28

The following article is from 覃佑桦 Author 覃佑桦

(给ImportNew加星标,提高Java技能)

编译:覃佑桦

suo.im/6wP5i7

本文记录了如何在 Kubernetes 上减小 JVM 应用容器占用的内存:哪些 JVM 标记更重要,如何正确设置以及如何测量参数对应用内存占用的影响。


故事从一个工作中的问题开始。笔者为 Wix 工作,作为数据流团队的一员负责所有的 Kafka基础设施。最近安排的任务是为 Node.js 服务建立一个 Kafka 客户端代理。


0 问题:Kafka 客户端 sidecar 内存泄漏


笔者的想法是将所有与 Kafka 相关的(生产和消费)操作从一个 Node.js 应用委托给一个独立的 JVM 应用。这种安排是为了适应我司的 Kafka 基础设施 — 客户端greyhound 采用 Scala 开发(开源版本)。


借助 sidecar 应用,Scala 代码不需要用其他语言重写,只需要一层薄薄的封装即可。



在生产环境部署 sidecar 后,立刻注意到内存占用飙升:

内存使用统计 — container_memory_working_set_bytes


从上面的表格可以看出,单是 sidecar 占用的内存已经达到了 node 应用容器的4到5倍。这里 sidecar 基于 openjdk 8 运行,统计时包含了 kafka 库。于是开始着手分析原因以及如何减少内存占用。


1 用生产数据实验


创建一个测试程序模仿该 node 应用的 sidecar,以便在不影响生产的前提下进行试验。测试应用包含了相同生产主题(production topic)的所有消费者。


通过将应用的 mxbeans暴露给 Prometheus/Grafana,可以用 heapMemoryUsed 和 nonHeapMemoryUsed 监控内存占用。当然,也可以用 jconsole 或 jvisualvm (JDK8或更高版本默认提供)。


首先试着梳理每个消费者、生产者以及 gRPC 客户端的影响。gRPC 客户端负责调用 node 应用。初步结论:增加或减少单个消费者不会对内存占用有显著影响。


2 JVM 堆标记


接着把注意力转向堆内存分配。有两个重要的 JVM 标志与堆分配有关:-Xms (启动时堆内存大小)和 -Xmx (最大堆内存)。尝试各种不同的组合并记录容器的内存使用情况。


使用不同堆标记时, 容器占用的总内存


结论一:当 Xmx 大于 Xms 时,如果某个应用使用的内存增大,分配的内存堆几乎肯定会达到 Xmx 的限制,导致容器总内存占用增大(参见下图比较)。


Xmx >> Xms

如果设置 Xmx 等于 Xms,由于堆内存大小不会随时间变化增大,从而可以更好地控制内存总量(参见下图比较)。


Xmx = Xms


结论二:只要一段时间内 GC 引发的 JVM 暂停时间不超过500ms,就可以放心减小 Xmx。这里使用 Grafana 监视 GC,也可以使用 visualgc 或 gceasy.io。


由 GC 引发的良性 JVM 暂停时间


设置 Xmx 时请注意:如果应用的消息吞吐量变化显著,那么每当有大量消息传入时,应用更容易受到 GC 风暴影响。


3 Kafka 相关调整


Greyhound (Kafka) 消费者有一个内部消息缓冲区可存储200条消息。当缓存消息最大值设为20时,可以注意到堆内存波动范围比 size=200 时更小(总体使用率更低):


bufferMax=200 堆内存使用情况


bufferMax=20 堆内存使用情况


当然,减少缓冲区意味着应用不能更好地处理突发情况。该方案不适合高吞吐量应用。为了弥补这个缺陷,可以将每个 pod 的 greyhound 消费者处理程序的并行性提高一倍,即把处理 Kafka 消息的线程从3个增加到6个。在发生异常情况下,要么为应用增加 prod,要么修改最大缓冲区配置。


把 Kafka 消费者 fetch.max.bytes (总查询消息大小) 从50M减少到5M对内存占用没有显著影响。从 sidecar 应用中提取 greyhound producer 得到的效果一样(这样可以在 DaemonSet 上驻留,从而在 K8s 节点上运行)。


4 减少内存有用的方法


优化后占用内存从 1000M 减少到 500-600M。下面这些有助于减少内存占用:


  • 堆分配大小保持一致: -Xms 等于 -Xmx;

  • 减少垃圾数量,例如 减少 Kafka 消息数量;

  • 利用 GC: 只要 GC 性能(新生代+老年代)没有显著降低(0.25% CPU时间),可以一直减小 xmx。


哪些行动不会带来(实质性)帮助:


  • 减少 KafkaConsumer 的 fetch.max.bytes;

  • 移除 Kafka producer;

  • 从 gRPC 客户端切换为 Wix 自定义 json-RPC 客户端。


5 接下来的工作


  • 调查 GraalVM 本地镜像是否有助于减少内存;

  • 比较不同的 GC 实现 (本文使用了 CMS,还可以尝试 G1);

  • 切换到基于 ZIO 的 greyhound 开源版本减少使用的 Kafka 线程数量;

  • 减少每个线程分配的内存(默认每个线程分配1MB)。


笔者会在接下来的文章中记录更多改进。


推荐阅读  点击标题可跳转

Docker 架构原理及简单使用

不要在 Docker 镜像中使用 Fat Jar

使用 Docker 搭建 Java Web 运行环境


看完本文有收获?请转发分享给更多人

关注「ImportNew」,提升Java技能

好文章,我在看❤️

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存