Nifi 1.6.0内存泄漏

Question

我们在生产中运行的是NiFi 1.6.0的Docker容器，必须遇到内存泄漏。

一旦启动，应用程序运行良好，然而，在4-5天的时间后，主机上的内存消耗继续增加。当在NiFi集群UI中签入时，JVM堆大小仅占30%左右，但是OS级别上的内存将达到80%-90%。

在运行docker命令时，我们发现NiFi停靠器容器正在消耗内存。

在收集了JMX指标之后，我们发现RSS内存不断增长。可能是什么原因造成的？在集群对话框的JVM选项卡中，年轻的GC似乎也在及时发生，旧GC计数显示为0。

我们如何确定是什么导致RSS内存增长？

Answer 1

您需要在非对接环境中进行复制，因为对于docker，内存是知养。

正如我在"Docker容器中运行的JVM的驻留集大小(RSS)和Java总提交内存(NMT)之间的差异“中解释的那样，docker有一些bug(如第10824期和第15020期)，这些错误阻止了对Docker容器中的Java所消耗的内存的准确报告。

这就是为什么像signalfx/docker-collectd-plugin这样的插件(两周前)在其PR --拉请求-- 35中提到“从内存使用率指标中减去缓存数字”的原因：

当前，返回给SignalFX的容器/cgroup的内存使用量计算包括Linux页缓存。 这通常被认为是不正确的，并可能导致人们在他们的应用程序中追逐幻影内存泄漏。 关于当前计算为什么不正确的演示，可以运行以下命令，查看I/O使用如何影响cgroup中的总体内存使用： docker run --rm -ti高寒猫/sys/fs/cgroup/memory/Memy.stat cat /sys/fs/cgroup/Memy.use_in_字节dd如果=/dev/零of=/tmp/myfile bs=1M count=100 cat /sys/fs/cgroup/Memy.stat cat /sys/fs/cgroup/Memy.stat cat /sys/fs/Memy.use_in_字节 您应该看到，仅通过创建一个100 by文件，usage_in_bytes值就会增加100 by。该文件尚未被应用程序加载到匿名内存中，但由于它现在位于页缓存中，容器内存的使用率似乎更高。 从memory.stat中从usage_in_bytes中扣除缓存数字表明，匿名内存的真正使用并没有增加。 现在，signalFX度量与运行码头统计数据时所看到的不同，后者使用了这里的计算。 似乎知道容器的页面缓存使用可能是有用的(尽管我很难考虑什么时候)，但是将它作为cgroup的总体使用百分比的一部分并不有用，因为它会掩盖您实际使用RSS内存的情况。 在具有最大堆大小或大于cgroup内存限制(例如java的-Xmx参数或服务器模式下的.NET核)的垃圾收集应用程序中，倾向于使百分比接近100%，然后在运行时能够正确查看cgroup内存限制的情况下，只停留在那里。 如果您正在使用智能代理，我建议使用码头-集装箱-状态监视器 (我将对其进行同样的修改以排除缓存内存)。

Answer 2

是的，NiFi停靠程序有内存问题，一段时间后就会出现故障，并自行重新启动。另一方面，非码头工人的工作非常好。

详细信息: Docker:以3gb堆大小运行它&启动后立即运行，消耗2gb左右。运行一些处理器，机器的风扇就会大量运行&过一段时间就会重新启动。

非码头:运行它的3gb堆大小&它需要900 3gb，运行平稳。(j控制台)