首页 文章

Nifi 1.6.0内存泄漏

提问于
浏览 次
4

我们正在 生产环境 运行NiFi 1.6.0的Docker容器，并且必须遇到内存泄漏 .

一旦启动，应用程序运行正常，但是，在4-5天后，主机上的内存消耗不断增加 . 在NiFi群集UI中检查时，JVM堆大小几乎不使用大约30％，但OS级别的内存大小为80-90％ .

在运行docker启动命令时，我们发现NiFi docker容器正在消耗内存 .

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

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

docker memory-leaks apache-nifi

1 回答

  • 2

    您需要在非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中提到"deduct the cache figure from the memory usage percentage metric"：

    目前，返回到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核心），趋势是百分比接近100 ％，然后只是悬停在那里，假设运行时可以正确地看到cgroup内存限制 . 如果您使用的是智能代理，我建议使用docker-container-stats监视器（我将对其进行相同的修改以排除缓存） .

    回复于

相关问题