Question

我们正在生产中运行NiFi 1.6.0的Docker容器，并且不得不遇到内存泄漏。

启动后，应用程序运行正常，但是，经过4-5天的时间，主机上的内存消耗一直在增加。在NiFi群集用户界面中进行检查时，JVM堆大小几乎不使用30％左右，但操作系统级别的内存却达到80-90％。

在运行docker starts命令时，我们发现NiFi docker容器正在占用内存。

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

我们如何确定导致RSS内存增长的原因？

Answer 1

您需要在非docker环境中复制该副本，因为对于docker，内存为known to raise。
正如我在“ Difference between Resident Set Size (RSS) and Java total committed memory (NMT) for a JVM running in Docker container”中所解释的那样，docker存在一些错误（例如issue 10824和issue 15020），这些错误导致无法准确报告Docker容器中Java进程消耗的内存。

这就是为什么像signalfx/docker-collectd-plugin这样的插件在两周前在其PR -- Pull Request -- 35中提到要“从内存使用率指标中减去缓存数据”：

当前，返回到SignalFX的容器/ cgroup的内存使用情况计算包括Linux页面缓存。
  通常认为这是不正确的，并且可能导致人们在其应用程序中追逐幻像内存泄漏。

有关当前计算为什么不正确的演示，您可以运行以下命令查看I / O使用情况如何影响cgroup中的整体内存使用情况：
docker run --rm -ti alpine
cat /sys/fs/cgroup/memory/memory.stat
cat /sys/fs/cgroup/memory/memory.usage_in_bytes
dd if=/dev/zero of=/tmp/myfile bs=1M count=100
cat /sys/fs/cgroup/memory/memory.stat
cat /sys/fs/cgroup/memory/memory.usage_in_bytes
您应该看到，usage_in_bytes值仅因创建100MB文件而增加了100MB。该文件尚未由应用程序加载到匿名内存中，但是由于它现在位于页面缓存中，因此容器内存使用率似乎更高。
  从usage_in_bytes中减去memory.stat中的缓存数字，表明对匿名内存的真正使用并未增加。

signalFX指标现在与运行docker stats时看到的不同，后者使用我在此处的计算。
  似乎知道对容器使用页面缓存可能很有用（尽管我很难考虑何时使用），但是将其作为cgroup总体使用率的一部分却无济于事，因为它会掩盖您的实际RSS内存使用。
  在最大堆大小等于或大于cgroup内存限制（例如，Java的-Xmx参数或服务器模式下的.NET Core）的垃圾收集应用程序中，趋势是百分比接近100 ％，然后将鼠标悬停在此处，假设运行时可以正确看到cgroup内存限制。
  如果您使用的是智能代理，建议您使用docker-container-stats monitor（我将对其进行相同的修改以排除缓存）。

Answer 2

是的，NiFi docker出现内存问题，一段时间后会启动并自行重启。另一方面，非docker绝对可以正常工作。

详细信息：码头工人：以3gb堆大小运行它，启动后立即消耗约2gb。运行一些处理器，机器的风扇大量运转，一段时间后重新启动。

非Docker：以3gb堆大小运行它，占用900mb并平稳运行。（jconsole）

Nifi 1.6.0内存泄漏

2 个答案: