我们正在进行一个项目，把基础架构从一个协同工作环境转移到亚马逊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.2G的交换空间，这是绝对不可能的，因为只有1G分配，没有使用（可能是因为仍然有1.8G的RAM空闲）。
这里是uname -a的结果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，但没有太多定制，也没有内核级定制。
这里的东西告诉我，在这个特定的内核/发行版上，交换或甚至总内存使用情况的报告不是看起来像…
任何帮助，将不胜感激！
实际上， jboss使用的是5.9GB的虚拟内存，没有交换空间。 top工具使用一个破坏的公式来计算它错误地报告为交换空间。 它实际上是从地址空间大小减去常驻集大小的结果。 这是一个头脑简单的事情，因为一个是虚拟内存的衡量标准，另一个是衡量物理内存。 所以结果甚至完全不是一个完全清楚的结果。 这个数字和老谜语中失踪的美元一样没有意义。
（实际上，这并不是完全没有意义的，如果程序当前的映射全部被弄脏了，程序的常驻大小没有改变，这是交换空间的最大数量，这真的是非常接近没有意义的考虑这些映射是否甚至是可写的。）