我有一個 .NET (Core 2.0) 服務，已從 AWS 上的 Windows 執行個體遷移到 Linux 執行個體。這些實例是微型實例，具有 1Gb RAM。
我為 linux 實例添加了 1Gb 交換空間，並設定了 swappiness=100，但是當實體記憶體被填滿時，伺服器凍結了。過程本身減慢到幾乎停止，甚至在 bash 上按 ENTER 有時也需要 10 秒才能出現新行。
運行時top我看到可用記憶體通常為 10、20mb。該進程使用 800Mb+ 的 RAM，且交換區始終幾乎為空，最多使用 20mb。即使在那裡租了一個小時也沒有交換更多的東西。
我可以看到 AWS 上的磁碟和 CPU 積分幾乎為 100%，因此它不會限制資源使用。另外，這樣的實例大約有一百個，我已經多次替換它們，行為總是相同的，所以它看起來不像壞實例問題。
令我困擾的是，這在 Windows 上並沒有發生，而 Linux 實例為基本系統使用了大約 200MB 的記憶體。
除了 swappiness 之外，我還需要調整其他設定才能讓 Linux 移動更多記憶體進行交換嗎？
編輯：交換已透過 cloud-init 正確設置，並且在重新啟動後仍能正常運作：
設定:
fallocate -l 1024M /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
sysctl vm.swappiness=100
free -m啟動後：
total used free shared buffers cached
Mem: 993 232 760 0 7 152
-/+ buffers/cache: 72 921
Swap: 1023 0 1023
答案1
我發現了真正的問題。該應用程式在 docker 內部運行，並且AWS 故意阻止 ECS 容器內的交換使用因為某些原因。這個區塊並沒有影響windows，因為我們之前沒有使用ECS來管理docker。
與他們的支援人員交談後，他們不支援容器內交換，也不知道什麼時候會支援。因此，我必須退出 ECS 並自行管理 docker。
答案2
好吧，你的錯誤實際上可能很小。高交換值會導致某些作業系統配置出現問題。嘗試使用像 15 這樣的值。在使用交換分割區之前，RAM 已釋放，因此15 表示在交換分割區之前必須使用85% 的RAM。
另外，你是如何增加交換空間的？如果您剛剛更改了配置並且沒有建立新分區，或者在 /etc/fstab 檔案中留下了錯誤，您將無法使用交換，並且當系統嘗試寫入不存在或不存在的內容時，一切都會中斷使用它無法寫入（或會發生更有趣的事情）。我已經透過這些方法破壞了不只一個安裝。