valgrind 显示的堆外程序内存消耗答案

【问题标题】：extra-heap program memory consumption as showed by valgrindvalgrind 显示的堆外程序内存消耗
【发布时间】：2011-07-19 16:16:07
【问题描述】：

我的程序使用了大量内存。这就是 valgrind massif 工具向我展示的内容：

--------------------------------------------------------------------------------
  n        time(i)         total(B)   useful-heap(B) extra-heap(B)    stacks(B)
--------------------------------------------------------------------------------
 28 38,531,086,036      760,235,208      143,002,822   617,232,386            0

如您所见，额外部分比有用堆大几倍。

我应该怎么做才能减少这些额外的内存？减少分配？

这就是所谓的内存碎片吗？

操作系统：Linux 2.6。程序是用 C 语言编写的。它应该 24 小时 7 小时工作，并且可以处理大量数据。

【问题讨论】：

你说它 24/7 运行？内存使用量是否会随着运行而增加？
不，它没有。没有内存泄漏。

标签： c linux heap-memory valgrind memory-fragmentation

【解决方案1】：

您是否分配了很多非常小的对象——比如说，只有几个字节？每次分配都有一定的开销（因为，例如，free 需要能够判断块有多大）。

这有时被称为“内部碎片”，而不是“外部碎片”，其中有一定数量的未分配内存但您无法使用它，因为它被分成太小而无法使用的块。（malloc 不会返回非常小的块的另一个原因是因为这有助于减少外部碎片。）

如果您正在分配大量非常小的对象，您应该考虑单独管理它们，而不是在堆上单独分配它们。如果你做得对，这在其他方面也可能会更好（例如，提高内存局部性）。

【讨论】：

恐怕我看不到用外部碎片交换内部碎片的好处。这真的是 malloc 阻塞额外空间的原因吗？
这是一个的原因。（这当然不是的原因。其他可能的原因：对齐，确保元数据有空间，减少大小类的数量以简化 malloc 内部。）最大外部碎片率类似于 log( max_size/granularity），尽管在实践中这是悲观的。因此，让所有块都是（比如说）8 或 16 字节的倍数可以减少外部碎片。它会增加内部碎片，但如果大多数块都很大，这并不重要。
open_memstream 是造成大量小额分配的罪魁祸首

【解决方案2】：

根据documentation，“extra-heap”字节如下：

额外的堆字节数在那个时候分配。这反映了分配的字节数超出了程序的要求。额外堆有两个来源字节。

首先，每个堆块都有与相关的管理字节它。行政部门的确切人数字节取决于的细节分配器。默认情况下，Massif 假定为 8 每个块的字节数，从这个例子，但这个数字可以是通过 --heap-admin 选项更改。

其次，分配器经常四舍五入要求更大的字节数数字，通常是 8 或 16。这是需要确保元素块内适当对齐。如果要求 N 个字节，Massif 将 N 向上舍入到最接近的倍数 --alignment 指定的值选项。

这听起来不像是内存碎片。

内存碎片通常是由大量的小分配引起的。您最终会在每个分配的内存单元之间产生很小的间隙，然后很难为更大的分配获得一个连续的内存区域。

为了防止内存分配基本上减少分配！尽可能使用堆栈空间（例如，不要不必要地使用 new），并尽可能考虑 pooling 频繁分配的对象，这样您就不会一直分配内存。

【讨论】：

您是否认为地块负责额外分配？并且它不会在被测程序的实际运行中发生？

【解决方案3】：

您可以减少分配更大尺寸或调整堆 - 后者将是特定于实现的。

这不是碎片，只是当您要求说 7 个字节时，堆分配 不少于 7 个字节 - 可以说是 16 个字节，所以 9 个字节成为“额外”并且实际上是浪费了。这样做有多种原因 - 例如，为了保持对齐。

【讨论】：