當 overcommit_memory==2 時 swapoff 失敗
我通過設置禁用了記憶體過度使用
overcommit_memory=2。現在，當我嘗試時swapoff，我收到此錯誤：swapoff：/dev/sda5：swapoff 失敗：無法分配記憶體
但我實際上有
0 MiB交換和大量可用記憶體！我嘗試設置overcommit_ratio為 100，但它沒有改變任何東西。如果我臨時設置
overcommit_memory=0為預設，我可以成功swapoff，然後重新禁用overcommitting。為什麼會有這種奇怪的行為？它是一個錯誤嗎？
按照評論中的要求進行編輯：
$ grep -E '^Mem|Commit' /proc/meminfo MemTotal: 2044420 kB MemFree: 751836 kB CommitLimit: 4122112 kB Committed_AS: 2752544 kB
正如@Mat 指出的那樣，Committed_AS > MemTotal。換句話說，你已經分配了比你實際擁有的更多的記憶體，所以如果你禁用交換，你就已經被過度使用了。因此，當您不允許過度送出時，您不能禁用交換，直到您釋放一些記憶體。
並非所有分配的記憶體都被實際使用，這就是為什麼儘管分配了這麼多記憶體，您仍然有一些空閒記憶體。
這是一個非常常見的混淆。有幾個概念只是鬆散相關。
- 物理記憶體使用
- 交換區使用
- 虛擬記憶體預留
- 虛擬記憶體分配
當一個程序分配記憶體（malloc 或類似的）時，它所做的實際上是保留記憶體。預設情況下，Linux 會過度使用虛擬記憶體，因此不太關心保留，通常會成功返回。
當您第一次訪問保留記憶體時，該記憶體必須由位於 RAM 或磁碟上的頁面支持。
如果沒有足夠的 RAM 來保存 RAM 上所有訪問的虛擬記憶體，則係統開始分頁（通常稱為交換）並且性能停止。
如果程序保留的記憶體多於交換區和（部分）RAM 的總和，並且您的系統配置為不過度使用記憶體，則分配失敗。即使您有大量可用 RAM 並且沒有使用交換區域上的任何頁面，這種情況也可能發生。這是擁有一個不會隨機殺死應用程序的系統所要付出的代價。
在您的情況下，您有足夠的可用虛擬記憶體，但其中一部分是保留的，因此要求存在一些交換區域，這意味著您無法刪除後者。