EC2 上的神秘交換使用

我們正在進行一個項目，將我們的基礎設施從 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 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，沒有太多自定義，而且絕對沒有核心級自定義。

這裡的一些東西告訴我，在這個特定的核心/發行版上，交換甚至總記憶體使用情況的報告並不是它看起來的樣子……

任何幫助，將不勝感激！

事實上，jboss是使用 5.9GB 的虛擬記憶體並且沒有交換空間。該top工具使用損壞的公式來計算它錯誤地報告為交換空間的內容。它實際上是從地址空間大小中減去駐留集大小的結果。這是一件愚蠢的事情，因為一個是虛擬記憶體的度量，另一個是物理記憶體的度量。因此，甚至根本不完全清楚結果是什麼。這個數字就像老謎語中失去的美元一樣毫無意義。

（實際上，它並非完全沒有意義。如果程序的目前映射都被弄髒並且程序的駐留集大小沒有改變，這是程序目前映射可能需要的最大交換空間量。這確實非常接近毫無意義，儘管它不需要考慮這些映射是否甚至是可寫的。）

引用自：https://serverfault.com/questions/371386