我们正处于一个项目的中间,将我们的基础架构从合作伙伴的情况转移到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 ggs的交换空间,这是绝对不可能的,因为只有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,没有太多自定义,绝对没有内核级自定义.
这里有些东西告诉我,在这个特定的内核/发行版中,交换或甚至总内存使用情况的报告并不像它看起来那么……
任何帮助,将不胜感激！
解决方法
事实上,jboss使用的是5.9GB的虚拟内存,没有交换空间.顶级工具使用破坏的公式来计算错误地报告为交换空间的内容.实际上是从地址空间大小中减去驻留集大小的结果.这是一个愚蠢的事情,因为一个是衡量虚拟内存,另一个是物理内存的衡量标准.所以结果甚至还不完全清楚.这个数字与
old riddle中的缺失美元毫无意义.
(实际上,它并非毫无意义.它是程序当前映射可能需要的最大交换空间量,如果它们都被弄脏并且程序的驻留集大小没有改变.这真的,非常接近于没有意义但尽管它不需要考虑这些映射是否甚至可写.)
