出现的问题是，在 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 的实现也不像会把自己噎死的样子）