关于公网分流任务使用 qBittorrent + libtorrent 内存泄漏的一些想法

出现的问题是,在 Linux qb 挂了 400+ 公网种子的情况下,使用 libtorrent 1.1 作为后端,在运行三至四天以后就会内存使用量不断增加,直到占用了几乎所有的可用内存,系统崩溃为止。

在 qb 的这个 Issue 中(https://github.com/qbittorrent/qBittorrent/issues/8630),有人在 Windows 上观察到了一样的现象,报告在 Enable OS cache 的情况下最终会导致内存泄漏。

在 https://github.com/qbittorrent/qBittorrent/issues/8295 和 https://github.com/arvidn/libtorrent/issues/1997 这两个 Issue 中,有人提到是 libtorrent 本身的 IO 和缓存实现存在问题,导致磁盘 IO 效率过低。但是这两个问题也都是在 Windows 上观察得出的,目前提供的方法是关闭 OS Cache,打开 libtorrent 的 coalesce reads & writes 选项,以在 Windows 上达到较好的 IO 性能表现(这个选项在 Linux 上是不必要的,因为 Linux 有 pwritev() 的实现,不需要通过 pwrite() 进行模拟——arvidn)。

但是在 Linux 上,这个问题仍然没有任何解决的迹象。在我看来,假定 libtorrent 自身的内存管理不存在问题,没有内存泄漏的情况,那么内存占用应该存在于两个方面:一是在 libtorrent 1.1 解决了 IO 性能问题以后引入的新 bug,即 lt 可以同时打开大量的 File Descriptor 且不陷入死锁,那么由于使用 buffered IO 的问题,在系统内核层面上消耗了大量的内存;另一个可能性是 TCP Socket buffer,libtorrent 1.1 相比 1.0 修正了大量 TCP Socket 连接卡死的问题(甚至出现了 too many open files 的情况,参见之前的文章,这个现象在 lt 1.0 从未出现过),大量 peer 和 tracker 连接使用的 TCP Socket 在内核层面占用了大量的内存,进而出现内存占用高的问题。

目前先禁用 OS Cache 进行下一步测试,观察是否还会出现内存占用过高。如果有,那么应该是 TCP 造成的问题了。(在看了 IBM 关于 Linux Direct IO 的这篇文章后,我对 IO Buffer 这个方向不报太大希望,因为无论怎么看 Buffered IO 的实现也不像会把自己噎死的样子)

发表评论

电子邮件地址不会被公开。 必填项已用*标注