Linux 上的虚拟内存大小

Virtual Memory size on Linux

提问by Arnaud G

I'm trying to understand in depth the virtual memory management on OS Linux.

我试图深入了解 OS Linux 上的虚拟内存管理。

I don't really understand how the OS determine the size of the VM for a process.

我真的不明白操作系统如何确定进程的 VM 大小。

I know that an 32-bits x86 OS can give up to 3 GB of vm adress space... Is it always true ?

我知道 32 位 x86 操作系统最多可以提供 3 GB 的 vm 地址空间......它总是如此吗？

In my case, i have about 110 MB physical memory with and 32-bits Linux, and my main process have a vm adress space about 660 MB. However, only 50 MB are in physical memory (the RSS of my process), so my physical RAM isn't full. The rest is free and almost the whole is used by page cache. That's seems to be a normal behaviour.

就我而言，我有大约 110 MB 的物理内存和 32 位 Linux，我的主进程有一个大约 660 MB 的虚拟机地址空间。但是，物理内存中只有 50 MB（我的进程的 RSS），所以我的物理 RAM 没有满。其余的都是免费的，几乎全部都被页面缓存使用。这似乎是一种正常的行为。

If i check /proc/my_process_PID/smap, there are several 8 MB anonymous VMA.

如果我检查 /proc/my_process_PID/smap，有几个 8 MB 的匿名 VMA。

My actual problem is that i need to make a additionnal 10 MB malloc in the code, but unfortunately OOM-Killer kills my process (out-of-memory) ... I think there are no more free available pages in the vm for the Heap, isn't it ? Is there an huge memory leak somewhere ?

我的实际问题是我需要在代码中创建一个额外的 10 MB malloc，但不幸的是 OOM-Killer 杀死了我的进程（内存不足）......我认为 vm 中没有更多可用的免费页面用于堆，不是吗？某处是否存在巨大的内存泄漏？

Why the OS doesn't extend my process vm size so ?

为什么操作系统不扩展我的进程虚拟机大小？

For information the vm size is unlimited : ulimit -v : unlimited

有关信息，虚拟机大小是无限制的： ulimit -v : 无限制

回答by Dietrich Epp

You can have 3GB of virtual memory per process (approximately, on many 32-bit Linux), and keep on creating new processes taking up gigabytes upon gigabytes of virtual memory. There's a small overhead in the kernel, but virtual memory is very cheap. The amount of address space you're using is probably not important, and it probably won't trigger the OOM killer.

每个进程可以有 3GB 的虚拟内存（在许多 32 位 Linux 上大约是这样），并继续创建新进程，占用数千兆字节的虚拟内存。内核的开销很小，但虚拟内存非常便宜。您使用的地址空间量可能并不重要，它可能不会触发 OOM 杀手。

However, your system only has so much RAM. As you start usingpages in your address space (writing to them), the kernel is forced to find physical RAM to map them to. If there's no physical RAM, the kernel can evict other pages from RAM -- either swap them out or discard them. But if it can't evict any pages, then it triggers the OOM killer.

但是，您的系统只有这么多 RAM。当您开始使用地址空间中的页面（写入它们）时，内核被迫寻找物理 RAM 以将它们映射到。如果没有物理 RAM，内核可以从 RAM 中驱逐其他页面——或者将它们换出或丢弃它们。但是如果它不能驱逐任何页面，那么它就会触发 OOM 杀手。

Running out of address space will cause mallocto return NULLon my system, instead of triggering the OOM killer.

耗尽地址空间将导致malloc返回NULL我的系统，而不是触发 OOM 杀手。

It sounds like your process is simply using too much RAM. RSS isn't the amount of memory your process uses, it's just the amount that's in physical RAM right now. If your process has a memory leak and keeps growing, RSS will eventually stop growing -- because for every new page you use, the kernel will evict one page from your process.

听起来您的进程只是使用了过多的 RAM。RSS 不是您的进程使用的内存量，它只是现在物理 RAM 中的量。如果您的进程有内存泄漏并不断增长，RSS 最终将停止增长——因为对于您使用的每个新页面，内核将从您的进程中逐出一页。

Try using a memory profiler, like Valgrind. This will help you sort out what memory you should be worried about (mallocs) and what memory you can ignore (shared libraries and other memory mapped files). The kernel (and /proc) won't give you enough detail.

尝试使用内存分析器，例如Valgrind。这将帮助您理清您应该担心哪些内存（mallocs）以及您可以忽略哪些内存（共享库和其他内存映射文件）。内核（和 /proc）不会给你足够的细节。

回答by Chris Dodd

The total amount of virtual memory space available on a linux system is (roughly) RAM+ swap space- kernel overhead. The RAM is the hardware you have installed and the kernel overhead is roughly a constant (varies between kernel versions though), so the only easy way to control the total VM space available is by adding or removing swap space.

Linux 系统上可用的虚拟内存空间总量（大致）是RAM+ swap space- kernel overhead。RAM 是您安装的硬件，内核开销大致恒定（尽管内核版本不同），因此控制可用 VM 总空间的唯一简单方法是添加或删除交换空间。

In addition to the total limit, there's also a per-process VM limit. This is configurable and (on 32bit linux at least) is at most 3GB, but may be quite a bit less. ulimit -vwill tell you this limit or can be used to change it.

除了总限制之外，还有每个进程的 VM 限制。这是可配置的，并且（至少在 32 位 linux 上）最多为 3GB，但可能会少很多。 ulimit -v会告诉你这个限制或者可以用来改变它。

When a process requests more VM space (generally via malloc), the kernel will look at all of these limits, and if any of them would be exceeded, will return 0. The OOM killer, on the other hand, only kicks in when you're getting close to the total VM limit. However, when the OOM killer kills you, you just die -- there's no out-of-memory error or any opportunity to catch it.

当一个进程请求更多的 VM 空间（通常通过 malloc）时，内核将查看所有这些限制，如果超过其中任何一个，将返回 0。另一方面，OOM 杀手仅在您正在接近总 VM 限制。然而，当 OOM 杀手杀死你时，你就死了——没有内存不足错误或任何抓住它的机会。

So if you really are running into the total VM limit, and want to avoid that, you can either allocate more swap space, or get rid of (kill or not start in the first place) other processes that are using a lot of VM space so as to free up some for your program.

因此，如果您确实遇到了 VM 的总限制，并且想要避免这种情况，您可以分配更多的交换空间，或者摆脱（首先终止或不启动）使用大量 VM 空间的其他进程以便为您的程序腾出一些。