我们正在进行一个项目，将我们的基础设施从 co-lo 迁移到 Amazon EC2，我们注意到我们的设置中的进程有一些奇怪的内存特性。我们不会过多地了解我们的进程的具体细节，我们注意到在我们的 EC2 实例上，“top”将显示使用很多交换空间 - 事实上，远远大于可用的交换量或（如果将其全部加起来）大于可用的磁盘量。
以下是顶部输出的示例：
Mem: 7136868k total, 5272300k used, 1864568k free, 256876k buffers
Swap: 1048572k total, 0k used, 1048572k free, 2526504k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND
4121 jboss 20 0 5913m 603m 14m S 0.7 8.7 3:59.90 5.2g java
22730 root 20 0 2394m 4012 1976 S 2.0 0.1 4:20.57 2.3g PassengerHelper
20564 rails 20 0 2539m 220m 9828 S 0.3 3.2 0:23.58 2.3g java
1423 nscd 20 0 877m 1464 972 S 0.0 0.0 0:03.89 876m nscd
比如说，你可以看到 jboss 据称使用了 5.2 GB 的交换空间，这绝对是不可能的，因为只分配了 1G，而且没有使用（可能是因为还有 1.8G 的可用 RAM）。
结果如下uname -a：
Linux xxx.yyy.zzz 2.6.35.14-106.53.amzn1.x86_64 #1 SMP Fri Jan 6 16:20:10 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
我们正在运行基于默认 Amazon Linux AMI（Amazon Linux AMI 版本 2011.09，因此有一些 RHEL5 和 RHEL 6）的 AMI，没有太多定制，当然也没有内核级定制。
这里有一些东西告诉我，在这个特定的内核/发行版上，交换或甚至总内存使用情况的报告并不是它看起来的那样......
任何帮助，将不胜感激！
答案1
事实上，jboss它使用了 5.9GB 的虚拟内存，没有交换空间。该top工具使用一个错误的公式来计算它错误地报告为交换空间的内容。它实际上是从地址空间大小中减去驻留集大小的结果。这是一个愚蠢的做法，因为一个是虚拟内存的度量，另一个是物理内存的度量。因此，结果到底是什么的度量并不完全清楚。这个数字就像计算器中缺失的美元一样毫无意义。老谜语。
（实际上，它并不是完全没有意义的。如果程序的当前映射都被弄脏并且程序的驻留集大小没有改变，那么它是程序当前映射可能需要的最大交换空间量。尽管它没有考虑这些映射是否完全可写，但这真的非常接近毫无意义。）