EC2 上的神秘交换使用

Question

我们正处于将我们的基础设施从 co-lo 情况转移到 Amazon EC2 的项目中，我们注意到我们设置中的进程有一些奇怪的内存特征。在没有详细介绍我们的进程的细节的情况下，我们注意到在我们的 EC2 实例上，“顶部”将显示使用大量交换空间的进程——事实上，远远大于可用交换空间或（如果你把它加起来）超过可用磁盘。

这是一个示例顶部输出：

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 gigs 的交换空间，这绝对是不可能的，因为只分配了 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，没有太多自定义，绝对没有内核级自定义。

这里的一些东西告诉我，在这个特定的内核/发行版上，交换或什至总内存使用情况的报告并不是它看起来的那样......

任何帮助，将不胜感激！

Answer 1

实际上jboss是使用了 5.9GB 的虚拟内存并且没有交换空间。该top工具使用一个错误的公式来计算它错误地报告为交换空间的内容。它实际上是地址空间大小减去常驻集大小的结果。这是一件愚蠢的事情，因为一个是虚拟内存的度量，另一个是物理内存的度量。因此，甚至根本不完全清楚结果是什么。这个数字就像老谜语中丢失的美元一样毫无意义。

（实际上，这并不是完全没有意义。这是程序的当前映射都被弄脏并且程序的驻留集大小没有改变时可能需要的最大交换空间量。这确实非常接近无意义，尽管它不需要考虑这些映射是否甚至可写。）