内存未释放回操作系统答案

【问题标题】：Memory not being released back to OS内存未释放回操作系统
【发布时间】：2019-02-23 17:41:32
【问题描述】：

我创建了一个图像大小调整服务器，它会创建一些不同的缩略图和您上传到它的图像。我正在使用包 https://github.com/h2non/bimg 来调整大小，它使用带有 c-bindings 的 libvips。

在投入生产之前，我已经开始使用 jmeter 对我的应用程序进行压力测试，并同时向其上传 100 张图像，连续几次，并注意到内存没有被释放回操作系统。

为了说明这个问题，我编写了几行代码来读取 100 张图像并调整它们的大小（不将它们保存在任何地方），然后等待 10 分钟。这样重复5次

我的代码和内存/CPU 图可以在这里找到： https://github.com/hamochi/bimg-memory-issue

很明显，内存正在被循环使用，否则它应该翻倍（我认为）。但它从未发布回操作系统。

这是 cgo 的一般行为吗？或者 bimg 正在做一些奇怪的事情。还是只是我的代码有问题？

非常感谢您提供的任何帮助！

【问题讨论】：

你确定是Go程序使用了内存吗？例如，这种用法是否包括文件系统缓存？你知道这是怎么衡量的吗？顶部显示什么？
是的，我也在用 Top 测量它，正如我们所说的，根据 top，该过程仍在使用 38.2%。当我使用 docker stats 监控它并在容器内运行它时，情况也是如此。我已经在我的回购顶部的屏幕截图中添加了。
相关，这解释了吗？ Cannot free memory once occupied by bytes.Buffer
我之前读过那篇文章，并决定将 bimg 更改为纯粹的 go 图像大小调整库（这比 libvips 需要更多内存）。正如帖子所解释的，内存最终被释放回操作系统，我也可以使用 debug.FreeOSMemory() 强制它。这不是 bimg 的情况，所以这就是为什么我要问这是否是一般 cgo 行为。
CGO 行为和 C 一样。你试过释放 vips 使用的缓存吗？

标签： go vips

【解决方案1】：

有一个 libvips 可以跟踪和调试引用计数 - 您可以尝试启用它并查看是否有任何泄漏。

https://libvips.github.io/libvips/API/current/libvips-vips.html#vips-leak-set

虽然从您上面关于 bimg 内存统计的评论来看，听起来可能一切正常。

从 Python 测试 libvips 内存很容易。我做了这个小程序：

#!/usr/bin/python3

import pyvips
import sys

# disable libvips operation caching ... without this, it'll cache all the
# thumbnail operations and we'll just be testing the jpg write
pyvips.cache_set_max(0)

for i in range(0, 10000):
    print("loop {} ...".format(i))
    for filename in sys.argv[1:]:
        # thumbnail to fit 128x128 box
        image = pyvips.Image.thumbnail(filename, 128)
        thumb = image.write_to_buffer(".jpg")

即。重复缩略图一组源图像。我是这样运行的：

$ for i in {1..100}; do cp ~/pics/k2.jpg $i.jpg; done
$ ../fing.py *

并在顶部观看了 RES。我看到了：

loop | RES (kb)
  -- | --
 100 | 39220
 250 | 39324
 300 | 39276
 400 | 39316
 500 | 39396
 600 | 39464
 700 | 39404
1000 | 39420

只要您没有引用计数泄漏，我认为您所看到的就是预期的行为。 Linux 进程只能在堆结束时将页面释放回操作系统（查看 brk 和 sbrk sys 调用）：

https://en.wikipedia.org/wiki/Sbrk

现在想象一下，如果 1) libvips 分配 6GB，2) Go 运行时分配 100kb，3) libvips 释放 6GB。由于堆末尾的 100kb 分配，您的 libc（您的进程中将代表您调用 sbrk 和 brk 的东西）无法将 6GB 交还给操作系统。一些 malloc 实现比其他实现具有更好的内存碎片行为，但默认的 linux 实现非常好。

在实践中，这并不重要。 malloc 将重用您的内存空间中的漏洞，即使没有，它们也会在内存压力下被分页，并且最终不会吃掉 RAM。尝试运行你的进程几个小时，然后观察 RES。您应该会看到它逐渐上升，但随后稳定下来。

（我根本不是内核人，以上只是我的理解，当然欢迎指正）

【讨论】：

非常感谢您的解释。我将运行我的过程几个小时，看看它是如何进行的。我希望它将内存释放回操作系统，因为这将帮助我更轻松地扩展我的服务，但我还有其他方法可以解决这个问题。与其他库相比，Libvips 的速度和内存效率仍然非常高，我肯定会坚持下去。
我的流程运行时间更长，持续了 17 个小时。第一次内存增加直到崩溃。第二次更稳定时，它增加到 78% 并一直存在，直到它停止调整大小（17 小时后）并下降到 65% 左右。它似乎足够稳定，我只需要确保它重新启动，以防它再次崩溃。
我添加了一个 py 程序来显示 libvips memuse。我在这里看到稳定的 40mb 左右。

【解决方案2】：

问题出在调整大小代码中：

_, err = bimg.NewImage(buffer).Resize(width, height)

图片是gobject，需要unref显式释放内存，试试：

image, err = bimg.NewImage(buffer).Resize(width, height)
defer C.g_object_unref(C.gpointer(image))

【讨论】：