tcmalloc碎裂

Question

我们的软件实现了一个参与者模型系统，我们经常分配/释放这个小对象，我确信每个对象都会被销毁，而不会有内存泄漏。(我使用了val研和tcmalloc工具来检查我的软件中的内存泄漏。没有发现泄漏。)

当我们改变使用tcmalloc替换glibc中的malloc时，我们发现内存不断增加，直到进程被OOM(内存不足)杀死为止。然后我们发现glibc也有同样的问题，但增长率低于tcmalloc。

我使用malloc_stats()来显示内存信息

第一次执行后(顶部显示0.96G)‘

• MALLOC: 960110592 ( 915.6 MB)堆大小
• MALLOC:应用程序正在使用的15886016 (15.2MB)字节
• MALLOC: 907419648 ( 865.4 MB)字节在页面堆中免费
• MALLOC: 0(0.0MB)字节在页堆中未映射
• MALLOC: 27121208字节( 25.9 MB)在中央缓存中免费
• MALLOC: 151040 (0.1MB)字节在传输缓存中免费
• MALLOC: 9532680 (9.1MB)线程缓存中的字节
• MALLOC:使用中的14275跨
• MALLOC: 27个正在使用的线程堆
• 分配7602176 (7.2MB)元数据

在第5次执行后(顶部显示1.2G)

• MALLOC: 1173131264 ( 1118.8 MB)堆大小
• MALLOC:应用程序使用的18001048字节(17.2MB)
• MALLOC: 1082458112 ( 1032.3 MB)字节在页面堆中免费
• MALLOC: 21168128 (20.2MB)字节在页堆中未映射
• MALLOC: 37992328 (36.2MB)字节在中央缓存中免费
• MALLOC: 252928 (0.2MB)字节在传输缓存中免费
• MALLOC: 13258720 (12.6MB)线程缓存中的字节
• MALLOC:使用中的17651跨
• MALLOC: 27个正在使用的线程堆
• 分配8126464 (7.8MB)元数据

从这些数据中我们可以看到。在第五次相同的行为之后，只有17.2在我们的软件中使用。但是tcmalloc保存1.1G内存，而不返回到系统。当然，tcmalloc保存这些内存并不重要。但是当我们的程序被OOM(实际使用的内存小于1G)杀死时，它却在不断增加。

我们怀疑它与堆碎片有关。有经验的人能和我们分享吗？我想我和bug.cgi?id=843478有同样的情况

非常感谢。

Answer 1

我建议在您的应用程序中使用博姆保守GC并使用GC_MALLOC和GC_MALLOC_ATOMIC代替malloc (在应用程序中使用GC_FREE而不是free，但是您甚至可以避免任何显式的free-ing，GC会这样做)。或者使用缬磨 (与系统Glibc一起)查找内存泄漏。如果使用Boehm的GC，不要忘记显式清除分配的内存区域。

最好确保您的许多小对象具有粗粒度。例如分配8或12或16字的对象，而不是8、9、10、11、12、13、14、15或16字的对象。例如，您可能只分配大小为2或3倍的大小的区域。

另外，不要忘记，您可以使用极限(2)限制内存空间，例如，在终端中运行bash的ulimit内置部分。这应该可以简化测试。此外，也许使用pmap或/proc/$(pidof yourapp)/maps可以帮助您理解所使用的地址空间。

PS。Boehm GC、nore任何类型的malloc (包括tcmalloc或Glibc malloc)都无法处理内存碎片问题。如果您怀疑碎片，您必须移动地址空间中的内存区域(也就是说，您可能希望对您自己的精确、复制、分代GC或重复使用一些现有的区域进行编码)。

Answer 2

tcmalloc试图做一些智能的事情来预测您的内存的使用，但是即使在释放了内存之后，将内存释放回系统也不是很好。事实上，它可能驻留在内存中并导致OOM。

这样做：

MallocExtension::instance()->ReleaseFreeMemory()；

当您的应用程序预期地释放了它预期不会很快使用的内存时。

有关http://google-perftools.googlecode.com/svn/trunk/doc/tcmalloc.html的更多信息，请参阅“将内存释放回系统”一节。

还有其他方法，例如设置释放率，但首先您可以在代码中添加这些方法，并检查驻留内存是否如预期的那样下降。