-2

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

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

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

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

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

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

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

4

2 回答 2

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")

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

$ 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。您应该看到它逐渐上升，但随后稳定下来。

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

于 2019-02-24T12:41:51.267 回答
0

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

_, 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))
于 2019-06-12T06:07:19.780 回答