了解虚拟内存使用情况>在Linux上交换+物理

我有一个进程在“顶部”报告它具有6GB的常驻内存和70GB的虚拟内存分配。奇怪的是，该特定服务器仅具有8GB物理空间和35GB可用交换空间。

从“顶部”手册中：

   o: VIRT  --  Virtual Image (kb)
      The total amount of virtual memory used by the  task.   It  includes
      all  code,  data  and  shared  libraries  plus  pages that have been
      swapped out. (Note: you can define the STATSIZE=1 environment  vari-
      able  and  the VIRT will be calculated from the /proc/#/state VmSize
      field.)

      VIRT = SWAP + RES.

有了这个解释，我希望为进程分配的虚拟内存仅限于我的swap +可用物理内存。

根据“ pmap”的介绍，此过程的代码，共享库和共享内存部分都非常小-不超过300M左右。

显然，机器和过程仍然可以正常运行（尽管运行缓慢），那么我在这里缺少什么呢？

可能需要零内存，而不是物理内存或页面文件中的内存。

您可能需要查看一些资源：

• http://www.gitam.edu/eresource/comp/gvr(os)/13.6.htm
• http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.system/2006-11/msg00176.html

您的应用程序会创建很多空的内存页面吗？如果是这样，您的应用程序可能会受益于：

• http://code.google.com/p/compcache/（实验）

它允许您压缩和解压缩实时内存页面。反过来，您可以将所有内容保留在RAM中，而不必交换到磁盘（非常慢）。

这是关于虚拟内存与常驻内存的讨论：

/programming/561245/virtual-memory-usage-from-java-under-linux-too-much-memory-used

讨论涉及Java进程，但适用于在Linux下运行的任何程序。关于病毒的主要观点是总数包括一堆永远不会使用的东西。对于32位OS，Virt是要考虑的东西（因为进程将达到可寻址空间的限制），但在其他方面则没有太大用处。如前所述，要注意的是驻留内存，它将限于可用的物理RAM和交换空间。

这可能是因为进程的地址空间是您所声明的大小，但OS并未真正分配它。

来自：http : //lwn.net/Articles/428100/

在尝试达到“足够低的开销且没有显着的延迟”的目标的过程中，Go开发人员做出了一些简化的假设，其中之一是，正在运行的应用程序所管理的内存来自单个虚拟连续的内存。地址范围。这种假设可能会遇到您的编辑器使用vi遇到的相同问题-其他代码可以在范围的中间分配部分-因此Go开发人员采用了相同的解决方案：他们只是分配他们认为可能需要的所有内存（他们认为，合理地讲，在启动时16GB在64位系统上就足够了）。

因此，这有时是不明确的内存管理方式-具有连续的地址空间可简化释放未使用的内存的过程。

答案可能是MMAP-数据在磁盘上，但是它在交换的“外部”，无法通过“ free”或“ top”命令看到。

如果Java进程不太复杂，则可以尝试使用“ lsof”来查找MMAP文件所在的位置。但是，如果此Java过程复杂，将很难看到。

我还感到惊讶的是，Linux允许您分配比物理内存+交换空间更多的虚拟内存，但是显然，它可以帮助提高典型情况下的性能。

幸运的是，有一个内核调整参数可用于切换内存计费模式。此参数是vm.overcommit_memory，它指示使用哪种算法跟踪可用内存。缺省值（0）使用启发式方法并过量使用虚拟内存系统。如果您希望程序在分配时收到适当的内存不足错误，而不是使进程遭受随机杀死，则应将此参数设置为2。

http://www.linuxjournal.com/article/10678