问题标签 [memory-fragmentation]

malloc 是否担心 linux 内核中的内部碎片？例如，当我要分配 5 个页面时，将 malloc 向上舍入大小使其成为 2:5->8 的幂，以避免内核内部碎片，因为 linux 内核使用伙伴系统作为页面分配器。

我读过Modern Operating Systems 4th Edition，Andrew Tanenbaum，其中介绍了一些处理内存管理的方法（使用位图，使用链表）和一些可用于分配内存的算法（第一次适合，下一次适合，最适合，最差，快速适合），它们是不同的，但没有一个是最好的。

我正在尝试制作自己的内存分配器，它将优先考虑尽可能低的外部碎片（内存块太小而无法使用）和分配/释放的速度（首先是碎片比速度）。我实现了最差的匹配（认为这将产生尽可能少的外部碎片，因为它总是在分配时选择最大的连续内存空间，并且该内存的剩余部分足以在以后用于另一个分配。我使用排序实现它可用空间的降序列表和按地址排序的已分配空间的集合。分配的复杂性是 O(1) + 维护列表排序和释放的成本 O(log n1) - 用于查找地址 + O(n2) - 用于解析空闲空间列表并插入找到的地址。n1 = 集合的元素，n2 = 列表的元素。

我有多个问题。首先是如何改进算法？其次，还有哪些其他用于内存分配的算法会优先考虑内存碎片？第三，我列出的算法是否有任何改进版本可以优先考虑内存碎片？我想知道尽可能多的算法/改进我所知道的算法的方法，这将减少外部碎片。

我知道我的问题太模糊了，但问题就在这里。我解析了一个非常大的文件，创建了我的对象的链接列表（顺便说一句，它们与位图无关）。有时我会遇到臭名昭著的“OutOfMemoryError”。在那之前，我看到了我自己的：

注意大量的可用内存。

之后我看到一堆 GC 消息，最后一条是：

显然我发现了这个错误，即使我永远无法断点它。GC 和 ActivityManager 之间的差异也是惊人的。问题是在那之后我无法继续，因为 GUI 无法为其数据分配内存。换句话说，发现这个错误为时已晚。所以我需要一些建议如何确定何时停止，以便程序仍然可以继续。请注意，我不需要如何优化我的数据的建议，因为无论它有多好，我总是可以用更大的文件使程序崩溃。

我对哈希表的理解是，它们使用哈希函数将键与内存中的位置相关联，并在内存中预先分配了总数的“桶”。目标是有足够的桶，我不必使用链接，将我理想的O(1)访问时间复杂度减慢到n/m x O(1)其中 n 是要存储的唯一键的数量，m 是桶的数量。

因此，如果我要存储 1000 个独特的项目，我将需要不少于 1000 个存储桶，并且可能需要更多存储桶，以尽量减少必须使用我的链表的可能性。如果不是这种情况，我们预计平均哈希表会有很多很多的冲突。现在，如果我们有 1000 个预分配的存储桶，这意味着我有 1000 字节的分配内存，分布在我的内存周围。因此，我的哈希表中的每个唯一键都会导致内存碎片，从而使我的 RAM 碎片化。

这是否意味着使用哈希表基本上可以保证产生与唯一键数量成正比的碎片量？此外，这似乎表明，如果您知道将有多少个唯一键，则可以使用一些统计信息来选择存储桶的数量，从而大大减少碎片化。是这样吗？

我有一个基于 ARM 的无头 Linux (v3.10.53-1.1.1) 系统，没有启用交换空间，即使有足够的 RAM 可用，我偶尔也会看到进程被 OOM-killer 杀死。

定期运行echo 1 > /proc/sys/vm/compact_memory似乎可以阻止 OOM 杀手，这让我认为内存碎片是罪魁祸首，但我不明白为什么用户进程无论如何都需要物理上连续的块；据我了解，即使在最坏的情况下（完全碎片化，只有单个 4K 块可用），内核也可以简单地分配必要数量的单个 4K 块，然后使用虚拟内存的魔力（tm）来制作它们看起来与用户进程连续。

有人可以解释为什么会调用OOM-killer来响应内存碎片吗？它只是一个错误的内核还是有真正的原因？（即使内核确实需要对内存进行碎片整理以满足请求，它不应该自动这样做而不是放弃和OOM'ing？）

我在下面粘贴了一个示例 OOM-killer 调用，以防它对事情有所启发。我可以随意重现故障；此调用发生在计算机仍有约 120MB 可用 RAM 的情况下（根据free），以响应我的测试程序分配内存，一次分配 10000 个 400 字节。

这也是我用来给系统施加压力并调用 OOM-killer 的测试程序（echo 1 > /proc/sys/vm/compact_memory命令经常运行，当free报告系统 RAM 接近于零时，OOM-killer 会出现，如预期的那样；没有它，OOM -killer 早在此之前就出现了，当free报告 130+MB 的 RAM 可用但之后cat /proc/buddyinfo显示 RAM 变得碎片化）：

我即将编写一个表示双端队列的类，就像 一样std::dequeue，但能够存储任何可破坏的类型，并且不支持索引。迭代或弹出操作只有在知道之前存储的类型时才会起作用。大多数情况下，它将用作队列/堆栈之类的存储，由其他类型引用，因为引用保证保持有效，即使它被推送/弹出到其间的任一端。内存的分配和释放应该在大块中完成。系统页面大小似乎非常适合默认块大小。

我认为，页面大小的内存块的页面对齐分配是有意义的，以减少迭代容器元素时的缓存未命中。这是真的？

恐怕使用std::aligned_alloc()with page alignment and size 会导致堆的元数据（例如，稍后需要free()知道分配的内存的大小）存储在分配的内存前面，这将导致巨大的浪费内存（每个分配的页面几乎一页）。或者对于堆的页面对齐内存分配是否有任何优化或不同的 API？例如，我可以想象一个 API 允许客户端指定存储所需元数据的位置，或者在分配时返回指向内存的指针和指向元数据的指针。

另一方面，使用系统原生 API（Windows / Posix / FreeRTOS）来分配页面将需要一个单独的内存池，这将是一个针对页面对齐内存分配进行优化的堆。但是有两个不知道彼此的堆也可能导致内存浪费，因为它们都有一个预先分配的页面池。还是大多数标准库实现一旦不再被客户端使用就将页面释放到操作系统？

让我澄清一下：我了解 new 和 delete（以及 delete[]）是如何工作的。我了解堆栈是什么，并且了解何时在堆栈和堆上分配内存。

然而，我不明白的是：堆上的内存分配在哪里。我知道我们应该将堆视为这个几乎无限 RAM 的大池，但事实并非如此。

什么可以控制选择堆内存的存储位置以及它是如何选择的？

另外：“将内存返回给操作系统”这个术语是我经常遇到的。这是否意味着堆在所有进程之间共享？

我之所以关心这一切，是因为我想了解更多关于内存碎片的知识。我认为在学习如何处理内存碎片之前了解堆的工作原理是个好主意，因为我没有足够的内存分配经验，也没有 C++ 直接深入研究。

我发现有用于连续内存分配的内核驱动程序。我虽然 malloc 合并内存并返回最佳匹配，如果内存不可用，它将返回 0。如果 malloc 只分配连续内存，那么需要像 PMEM 这样的连续内存分配器。

我的问题如下

1. 是不是因为虚拟内存没有碎片但是物理页面是碎片的？

谢谢你。

我一直在学习 C++，并且遇到了自定义内存分配器的主题。我了解到，通过设计一个分配器并将这个分配器与标准库容器一起使用，我们可以避免堆分配。此外，我们似乎可以避免内存碎片。这部分是通过使用placement new 和placement delete 操作符来实现的。

是否也可以在 C 中设计自定义内存分配器，以便我们可以控制内存分配并避免碎片？如果可能的话，C++ 是否只是简单地提供这种具有更高抽象级别的功能？

我正在开发的 C#/.NET 应用程序使用了巨大的字节数组，并且存在内存碎片问题。使用 CLRMemory 检查内存使用情况

我们使用的代码如下

我们在整个应用程序的多个位置使用类似的代码，我们将其称为循环以生成从几百到 10000 的批量审计

1. 现在有没有更好的方法来处理这个以避免碎片

作为审计的一部分，我们还使用以下代码从 Amazon S3 下载大文件

2. 有没有更好的选择来下载大文件而不将它们移动到 LOH，这对垃圾收集器造成了损失