感谢您的阅读！如果您想了解我在Kafka，Scala，ZIO和JVM方面的最新信息，请在Twitter和Medium中关注我。 如果有任何不清楚的地方，或者您想指出点什么，请在下方留言。

> Photo by Franck V. on Unsplash

最近，我设法大大减少了Kubernetes上一个广泛使用的JVM应用程序容器的内存使用量，并节省了很多钱。 我弄清楚了哪些JVM标志更重要，如何正确设置它们以及如何轻松衡量我的操作对应用程序内存使用的各个部分的影响。 这是我的悬崖笔记。

故事从一个用例开始。 我作为数据流团队的一员在Wix工作，负责我们所有的Kafka基础架构。 最近，我负责为Node.js服务创建Kafka客户端代理。

用例：Kafka客户端sidecar浪费内存

这个想法是将所有与Kafka相关的动作(例如生产和消费)从Node.js应用委托给单独的JVM应用。 其背后的动机是，我们许多针对Kafka客户的基础架构都是用Scala编写的(称为greyhound-可以在此处找到开放源代码版本)。有了Sidecar，Scala代码不需要在其他代码中重复语言。 只需要一个薄的包装。

一旦将Sidecar部署到生产中，我们注意到它会消耗大量内存。

> Metric used — container_memory_working_set_bytes

从上表中可以看到，仅用于sidecar(运行openjdk 8)的内存占用量是过去包含kafka库的node-app容器的4-5倍。

我必须了解为什么以及如何大幅减少它。

试验生产数据

我着手创建一个模拟该特定节点应用程序的sidecar的测试应用程序，以便能够在不影响生产的情况下自由地对其进行实验。 该应用程序包含生产应用程序中所有生产相同主题的消费者。

作为监视内存消耗的一种方式，我使用了从我的应用程序内部的mxbeans暴露给Prometheus / Grafana的指标，例如heapMemoryUsed和nonHeapMemoryUsed，但是您也可以使用jconsole或jvisualvm(均与JDK 8或更高版本捆绑在一起)

首先，我试图了解每个消费者和生产者以及gRPC客户端(称为节点应用程序)的影响，得出的结论是，拥有一个(或更少)一个消费者并不会影响有意义的内存占用。 道路。

JVM堆标志

然后，我将注意力转向堆分配，有两个重要的JVM标志与堆分配有关-Xms(启动时堆内存大小)和-Xmx(最大堆内存大小)

我尝试了两者的许多不同组合，并记录了由此产生的容器内存使用情况：

> Container overall used memory with different heap flags

通过分析有关堆标志变化的数据得出的第一个结论是，如果Xmx高于Xms，并且您的应用程序具有很高的内存压力，那么分配给堆的内存几乎肯定会继续增长 到Xmx限制，导致容器的整体内存使用量也增加(请参见下表中的比较)。

> Xmx >> Xms

但是，如果Xmx与Xms相同，则可以对整体内存使用量进行更多控制，因为堆不会随时间逐渐增加(请参见下面的比较)。

> Xmx = Xms

我从堆标志数据得出的第二个结论是，只要您没有看到由于垃圾回收(GC)导致JVM暂停的时间很长，就可以显着降低Xmx —长时间超过500ms 。 我再次使用Grafana监视GC，但是您也可以使用visualgc或gceasy.io

> benign JVM pause times due to GC

请注意为Xmx设置的数字-如果您的应用程序在消息消耗吞吐量方面有很大差异，一旦您的应用程序遇到大量传入消息，您的应用程序将更容易受到GC风暴的影响。

Kafka相关的调整

我们的灵狮(Kafka)使用者有一个内部消息缓冲区，该缓冲区可以获取多达200条消息。 当我将最大允许大小减小到20时，我注意到堆内存使用率的波动范围比size = 200窄得多(总体上使用率也很低)：

> Heap memory usage pattern when bufferMax=200

> Heap memory usage pattern when bufferMax=20

当然，减小缓冲区大小意味着该应用程序将无法很好地处理突发事件-因此这不适用于高吞吐量应用程序。 为了减轻这种情况，我将每个Pod的灰狗消费者处理程序的并行度提高了一倍。 也就是说，我将处理Kafka消息的线程数从3个增加到6个。在异常情况下，该应用将需要更多的Pod，或者必须更改最大缓冲区配置。

将Kafka Consumer fetch.max.bytes从50M减少到5M(以减少轮询的消息总大小)对内存占用没有明显的影响。 也没有从sidecar应用程序中提取出灵缇生产者(它可以驻留在DaemonSet中，因此它将在每个K8s节点上运行)。

摘要—有助于减少内存使用的因素

我进行的优化将容器内存使用量从1000M减少到了550-600M。 以下是有助于减少占用空间的更改：

· 保持一致的堆大小分配-Xms等于-Xmx

· 减少废弃物品(垃圾)的数量 缓冲较少的Kafka消息

· 只要GC(新一代+老一代)所用的百分比不高(CPU时间为0.25％)，GC就可以继续降低XMX

没有帮助的(基本上)

· 减少KafkaConsumer的fetch.max.bytes

· 删除Kafka生产者

· 从gRPC客户端切换到Wix的自定义json-RPC客户端

未来的工作

· 探索GraalVM本机映像是否可以提供帮助

· 比较不同的GC实现。 (我使用过CMS，但有G1)

· 通过切换到基于开源ZIO的灵狮，减少从Kafka消费时使用的线程数。

· 减少为每个线程分配的内存(默认情况下，为每个线程分配1MB)

肯定会有更多的改进(以及第二篇博客文章)。

更多信息

Docker内存资源限制和一堆Java —博客文章

GeekOUT会议上的Java流程视频的内存占用量

(本文翻译自Natan Silnitsky的文章《How to reduce your JVM app memory footprint in Docker and Kubernetes》，参考：https://medium.com/wix-engineering/how-to-reduce-your-jvm-app-memory-footprint-in-docker-and-kubernetes-d6e030d21298)