问题标签 [memory-overcommitment]

我想在我的进程中为以前使用但目前不需要的内存保留虚拟地址空间。我对主机内核是 Linux 的情况感兴趣，并且它被配置为防止过度使用（它通过详细说明所有已提交的内存来实现）。

如果我只是想防止我的应用程序不再使用的数据占用物理内存或被交换到磁盘（无论哪种方式都浪费资源），我可以madvise使用不需要它的内核，或者mmap在它上面添加新的零页。但是这两种方法都不一定会减少算作已提交的内存量，然后阻止其他进程使用这些内存量。

如果我用标记为只读的新零页替换这些页面怎么办？我的意图是它们不计入已提交的内存，并且我以后可以使用mprotect它们使它们可写，并且如果使它们可写将超过已提交的内存限制，它将失败。我的理解正确吗？这行得通吗？

这是在 CentOS 64 位上使用 G++ 4.1.2 的 C++。

我们正在编写一个测试应用程序以将系统上的内存使用量加载 n GB。这个想法是通过SNMP等监控整个系统负载。所以这只是一种进行监控的方式。

然而，我们看到的是简单地做：

不影响使用的内存，如 top 或 free -m 所示

一旦内存被写入，内存分配似乎才变得“真实”：

但是我们必须写入所有内存，简单地写入第一个元素并不会显示已用内存的增加：

这是正常的吗，内存真的被完全分配了吗？我不确定是否是我们正在使用的工具（top 和 free -m）显示不正确的值，或者编译器或运行时和/或内核中是否发生了一些聪明的事情。

即使在关闭优化的调试版本中也可以看到此行为。

我的理解是 new[] 立即分配了内存。C++ 运行时是否会延迟此实际分配，直到稍后访问它。在这种情况下，内存不足异常可以推迟到实际分配内存之后直到访问内存吗？

因为它对我们来说不是问题，但很高兴知道为什么会这样！

干杯!

编辑：

我不想知道我们应该如何使用 Vectors，这不是 OO / C++ / 当前的做事方式等等。我只想知道为什么会这样，而不是有建议尝试其他方法。

您可以通过 sysctls 调整系统范围内的内存过量使用策略，但是否可以在进程本身内基于每个进程调整此策略？我想让一个特定的实时进程从不使用过度使用，尽管系统的其余部分可以过度使用。

如果内存不能立即可用，有没有办法尝试分配内存块并得到错误？

calloc() 似乎是一个不错的候选者，因为它会立即触及整个分配的内存，但是，我猜它会终止进程而不是返回 NULL。

还有其他选择吗？

父进程在尝试 fork 子进程时失败并显示 errno=12(Out of memory)。父进程在 Linux 3.0 内核 - SLES 11 上运行。在分叉子进程时，父进程已经使用了大约 70% 的 RAM（180GB/256GB）。这个问题有什么解决方法吗？

该应用程序是用 C++ 编写的，使用 g++ 4.6.3 编译。

是否有一种悲观的方式来确定 malloc 是否会失败。我有点担心这个：

默认情况下，Linux 遵循乐观的内存分配策略。这意味着当 malloc() 返回非 NULL 时，不能保证内存确实可用。如果发现系统内存不足，OOM 杀手将杀死一个或多个进程。有关详细信息，请参阅 proc(5) 中 /proc/sys/vm/overcommit_memory 和 /proc/sys/vm/oom_adj 的说明，以及 Linux 内核源文件 Documentation/vm/overcommit-accounting。

如果我不知道这个免责声明，我会检查 malloc 是否成功。

在我的情况下，内存是一个约束，因为应用程序需要分配一个大数据块（千兆字节）。Gimp 通过其配置对话框将全部责任转移给用户。我想要一些可以推断出软上限的东西。

我正在尝试测量 CPU 过度使用对 KVM 设置（主机和来宾）的影响。当 vCPU 数量增加时，我可以检测到性能下降，但理想情况下，我想查看一些更客观的指标（例如 esxtop 中的 CPU Ready）。是否有提供类似指标的 KVM 的 esxtop 等效项。

如何在不过度使用的情况下在 Linux 上分配内存，以便 mallocNULL在没有可用内存并且进程在访问时不会随机崩溃时实际返回？

我对 malloc 工作原理的理解：

1. 如果有空闲内存，分配器会检查空闲列表。如果是，则分配内存。
2. 如果否，则从内核分配新页面。这将是可能发生过度使用的地方。然后返回新的内存。

因此，如果有一种方法可以从内核获取由物理内存立即支持的内存，分配器可以使用它而不是获取过度使用的页面，并NULL在内核拒绝提供更多内存时返回。

有没有办法做到这一点？

更新：

我知道这不能完全保护进程免受 OOM 杀手的影响，因为如果它的分数不好，它仍然会在内存不足的情况下被杀死，但这不是我担心的。

更新 2： Nominal Animal 的评论给了我以下使用的想法mlock：

但这可能由于所有系统调用而相当慢，因此这可能应该在分配器实现级别完成。而且它还阻止了使用交换。

更新 3：

遵循 John Bollingers 的评论的新想法：

1. 检查是否有足够的内存可用。据我了解，这必须/proc/meminfo在MemFreeandSwapFree值中进行检查。
2. 仅当有足够的可用空间（加上额外的安全余量）时，才分配内存。
3. 找出getpagesize每个页面大小的页面大小并将一个字节写入内存，以便它得到物理内存（RAM或交换）的支持。

我还更仔细地查看了mmap(2)并发现以下内容：

MAP_NORESERVE

不要为此映射保留交换空间。保留交换空间时，可以保证可以修改映射。如果没有保留交换空间，如果没有可用的物理内存，可能会在写入时获得 SIGSEGV。另请参见 proc(5) 中对文件 /proc/sys/vm/overcommit_memory 的讨论。在 2.6 之前的内核中，此标志仅对私有可写有效

这是否意味着映射~MAP_NORESERVE将完全保护进程免受 OOM 杀手的影响？如果是这样，这将是一个完美的解决方案，只要有一个malloc可以直接在mmap. （也许是jemalloc？）

更新 4： 我目前的理解是，这~MAP_NORESERVE不会防止 OOM 杀手，但至少可以防止第一次写入内存时出现段错误。

假设我在具有 64 Gb RAM 的 64 位 Linux 机器上运行我的程序。在我开始后立即执行的非常小的 C 程序中

这将我的数据段向前移动了 120 Gb。

在我的进程的上述sbrk调用top条目显示RES为某个低值之后，VIRTat120g和SWAPat 120g。

在此操作之后，我在上述区域的前 90 Gb 中写入了一些内容

top这导致我的流程的条目发生了一些变化：VIRT预期保持在120g，RES几乎变成64g，SWAP下降到大约56g。

Swap输出标题中的常见统计数据top显示交换文件使用量增加，这是预期的，因为我的程序必须将大约 26 Gb 的内存页面推送到交换文件中。

因此，根据上述观察，SWAPcolumn 仅报告我的进程的非RES地址空间，而不管该地址空间是否已“物化”，即无论我是否已将某些内容写入该虚拟内存区域。

但是有没有办法弄清楚这个SWAP大小中有多少实际上已经“物化”并由存储在交换文件中的东西支持？即有什么方法可以top为我的进程显示 26 Gb 的值吗？

如果 ram 内存被 Openstack 管理程序过度使用，我怎么能从虚拟机中的操作系统知道？

我的应用程序被操作系统杀死导致内存不足错误，但我已将堆和元空间配置为总可用内存的 70% 以下。

我无权访问 openstack 配置。

提前致谢。