Log for Ubuntu 台灣社群
為 swap 辯護：常見誤解解析 (2018) （★ 100 分）
作者試圖為 Linux 的 swap 機制辯護，釐清長期以來的誤解。許多人視 swap 只是「緊急額外記憶體」，但實際上它更重要的角色是在於「公平的回收機制」：讓匿名記憶體（anon memory，無法直接丟棄的頁面）也能透過 swap 被移到儲存裝置，從而像檔案快取一樣具備可回收性。如果完全停用 swap，整體記憶體回收效率會下降，甚至可能導致更嚴重的磁碟 I/O 抖動。文章特別指出，Linux 4.0 以前的核心 swap 行為確實有過度積極的問題，因此留下負面印象，但新核心已改善許多。對於 SSD 來說，回收檔案頁面與 swap 匿名頁在效能上差異不大，而旋轉磁碟則因隨機讀取昂貴，才需要調整 `vm.swappiness`。作者反覆強調：真正拖慢系統的是進入整體記憶體壓力，而不是有沒有啟用 swap。
文章進一步比較了有無 swap 的不同情境。在低壓力下，swap 能釋放長期閒置的匿名記憶體，讓快取命中率更高；沒有 swap 則會導致無法利用這些記憶體空間。在中高壓力下，有 swap 則回收資源的選擇更多，降低頻繁的頁面抖動；沒有 swap 則使匿名頁固定鎖死在 RAM，讓回收效率更差。在突發性的需求尖峰中，啟用 swap 會讓系統撐更久，但同時也可能延遲到 OOM killer（記憶體不足時的最後手段）出手。作者認為最佳策略是搭配 cgroup v2 提供的 `memory.low` 來調整，不要單靠全域的 OOM killer，因為它出手時已經太遲。至於 swap 大小，作者建議在新核心下多一點沒壞處，但最有效的方法是透過觀察實際負載，找到合適容量，並針對不同應用測試 `vm.swappiness` 的設定。
在 Hacker News 的討論中，許多工程師分享了實務經驗。一派人強調「快死比慢死好」，他們寧可程式在 OOM 立即被殺掉，也不要整個系統因 swap 抖動而長時間無法回應，特別在雲端與分散式系統中，掛掉一台機器比拖慢整片叢集還好。另一派則認為 swap 對於長期常駐程式或 Java 這類配置龐大的應用特別重要，可將使用頻率低的匿名頁移出，釋放 RAM 給檔案快取，顯著改善效能。還有人指出，在伺服器上可以搭配 zram 或 zswap（記憶體壓縮 swap 技術），減少對實體磁碟的依賴，特別是當現代 NVMe SSD 可做為「便宜 RAM」使用時，能節省大量成本，例如有公司就用 512GB RAM + 3.9TB NVMe 交換空間取代全 RAM 配置，節省達 97%。
有些評論提醒，Linux 的 OOM killer 經常「殺錯程式」，導致系統出現難以預期的行為，因此若沒有細緻的資源隔離（如 cgroup），大 swap 反而會拖延問題浮現。幾位參與者比較了 Linux 與 BSD：BSD 傾向直接讓程式分配失敗，而不是拖到 OOM，這讓行為更可預測。此外，還有人討論了 swap 對 SSD 壽命的影響，不過多數人認為在雲端環境中這不大是問題，因為雲平台會管理底層 SSD 磨損。對於桌機使用者，有人抱怨 swap 會讓某個失控程式吃掉全部 RAM 之後，整個系統所有應用都被換出，導致長時間卡頓；這時不少人會建議減少 swap 容量而不是完全停用。
總結來看，文章與討論凸顯出一個現代共識：swap 不再是單純的「老掉牙備用 RAM」，而是一個輔助記憶體管理、提升公平回收與成本效益的工具。如何使用，取決於場景：對伺服器與多工環境，適度配置與合理調 tuning 能帶來實質好處；對需要高即時性的系統，則可能讓問題更嚴重。最關鍵的差異，不在於「要不要 swap」，而在於「如何妥善運用」它。
👥 94 則討論、評論 💬
https://news.ycombinator.com/item?id=45318798
作者試圖為 Linux 的 swap 機制辯護，釐清長期以來的誤解。許多人視 swap 只是「緊急額外記憶體」，但實際上它更重要的角色是在於「公平的回收機制」：讓匿名記憶體（anon memory，無法直接丟棄的頁面）也能透過 swap 被移到儲存裝置，從而像檔案快取一樣具備可回收性。如果完全停用 swap，整體記憶體回收效率會下降，甚至可能導致更嚴重的磁碟 I/O 抖動。文章特別指出，Linux 4.0 以前的核心 swap 行為確實有過度積極的問題，因此留下負面印象，但新核心已改善許多。對於 SSD 來說，回收檔案頁面與 swap 匿名頁在效能上差異不大，而旋轉磁碟則因隨機讀取昂貴，才需要調整 `vm.swappiness`。作者反覆強調：真正拖慢系統的是進入整體記憶體壓力，而不是有沒有啟用 swap。
文章進一步比較了有無 swap 的不同情境。在低壓力下，swap 能釋放長期閒置的匿名記憶體，讓快取命中率更高；沒有 swap 則會導致無法利用這些記憶體空間。在中高壓力下，有 swap 則回收資源的選擇更多，降低頻繁的頁面抖動；沒有 swap 則使匿名頁固定鎖死在 RAM，讓回收效率更差。在突發性的需求尖峰中，啟用 swap 會讓系統撐更久，但同時也可能延遲到 OOM killer（記憶體不足時的最後手段）出手。作者認為最佳策略是搭配 cgroup v2 提供的 `memory.low` 來調整，不要單靠全域的 OOM killer，因為它出手時已經太遲。至於 swap 大小，作者建議在新核心下多一點沒壞處，但最有效的方法是透過觀察實際負載，找到合適容量，並針對不同應用測試 `vm.swappiness` 的設定。
在 Hacker News 的討論中，許多工程師分享了實務經驗。一派人強調「快死比慢死好」，他們寧可程式在 OOM 立即被殺掉，也不要整個系統因 swap 抖動而長時間無法回應，特別在雲端與分散式系統中，掛掉一台機器比拖慢整片叢集還好。另一派則認為 swap 對於長期常駐程式或 Java 這類配置龐大的應用特別重要，可將使用頻率低的匿名頁移出，釋放 RAM 給檔案快取，顯著改善效能。還有人指出，在伺服器上可以搭配 zram 或 zswap（記憶體壓縮 swap 技術），減少對實體磁碟的依賴，特別是當現代 NVMe SSD 可做為「便宜 RAM」使用時，能節省大量成本，例如有公司就用 512GB RAM + 3.9TB NVMe 交換空間取代全 RAM 配置，節省達 97%。
有些評論提醒，Linux 的 OOM killer 經常「殺錯程式」，導致系統出現難以預期的行為，因此若沒有細緻的資源隔離（如 cgroup），大 swap 反而會拖延問題浮現。幾位參與者比較了 Linux 與 BSD：BSD 傾向直接讓程式分配失敗，而不是拖到 OOM，這讓行為更可預測。此外，還有人討論了 swap 對 SSD 壽命的影響，不過多數人認為在雲端環境中這不大是問題，因為雲平台會管理底層 SSD 磨損。對於桌機使用者，有人抱怨 swap 會讓某個失控程式吃掉全部 RAM 之後，整個系統所有應用都被換出，導致長時間卡頓；這時不少人會建議減少 swap 容量而不是完全停用。
總結來看，文章與討論凸顯出一個現代共識：swap 不再是單純的「老掉牙備用 RAM」，而是一個輔助記憶體管理、提升公平回收與成本效益的工具。如何使用，取決於場景：對伺服器與多工環境，適度配置與合理調 tuning 能帶來實質好處；對需要高即時性的系統，則可能讓問題更嚴重。最關鍵的差異，不在於「要不要 swap」，而在於「如何妥善運用」它。
👥 94 則討論、評論 💬
https://news.ycombinator.com/item?id=45318798
個人建議，確定記憶體夠用，可以考慮不設定
但若沒有非常有把握，建議還是開 swap，另外再修改 swapness
ps. 記憶體不夠，又沒有 swap，會直接 kernal panic
但若沒有非常有把握，建議還是開 swap，另外再修改 swapness
ps. 記憶體不夠，又沒有 swap，會直接 kernal panic
之前從網路上複製了一段 script，可以列出目前在 swap 的 proccess 以及資料大小，可以觀察一下是否需要 swap
for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | head英國銀行仍在運作 1960 年代撰寫的程式碼
英國銀行至今仍在運作 1960 年代撰寫的程式碼，而了解這些程式碼的人已經寥寥無幾。根據對 200 家英國銀行的調查，有 16% 的銀行仰賴 1960 年代的軟體，將近 40% 的銀行仍在維護 1970 年代的程式碼。50% 的銀行承認，他們仰賴的軟體只有一兩位已經或即將退休的員工了解。31.5% 的銀行表示，他們依賴一兩位尚未到退休年齡的員工來掌握舊系統。共有 38 家銀行指出，他們仍在使用當初設計於穿孔卡等實體系統上運作的程式碼；另有 15% 的銀行仍在運作為房間大小大型主機所撰寫的程式碼。由於銀行體系龐大，不太可能在每一次科技革新時就全面重構基礎設施。一位受訪者表示，他所在的銀行核心系統建立於 1970 年代，至今仍在使用 Cobol 語言。
英國銀行至今仍在運作 1960 年代撰寫的程式碼，而了解這些程式碼的人已經寥寥無幾。根據對 200 家英國銀行的調查，有 16% 的銀行仰賴 1960 年代的軟體，將近 40% 的銀行仍在維護 1970 年代的程式碼。50% 的銀行承認，他們仰賴的軟體只有一兩位已經或即將退休的員工了解。31.5% 的銀行表示，他們依賴一兩位尚未到退休年齡的員工來掌握舊系統。共有 38 家銀行指出，他們仍在使用當初設計於穿孔卡等實體系統上運作的程式碼；另有 15% 的銀行仍在運作為房間大小大型主機所撰寫的程式碼。由於銀行體系龐大，不太可能在每一次科技革新時就全面重構基礎設施。一位受訪者表示，他所在的銀行核心系統建立於 1970 年代，至今仍在使用 Cobol 語言。
如果覺得 Python 錯誤訊息很多的話，建議不要碰 Rust
有誤到問題的話，可以把電腦硬體、軟體名稱、軟體版本和錯誤訊息一起整理一下，這邊應該不少有經驗的人可以幫忙
(先把資料整理好，不然沒有人知道發生什麼事)
有誤到問題的話，可以把電腦硬體、軟體名稱、軟體版本和錯誤訊息一起整理一下，這邊應該不少有經驗的人可以幫忙
(先把資料整理好，不然沒有人知道發生什麼事)
若覺得 Windows 沒錯誤訊息，只是他沒有讓你看到而已，一般使用者看到錯誤訊息都快嚇死了，根本不會買
Linux / Unix 的生態，比較透明，不管有沒有錯誤都會有記錄，使用者有權力決定要不要看訊息
Linux / Unix 的生態，比較透明，不管有沒有錯誤都會有記錄，使用者有權力決定要不要看訊息
意思是以前的Win 95 > win 11 ? 因為當時的安裝難度很高所以等於他很讚 ?
相反現在的ubuntu < 以前的ubuntu 因為現在的安裝越來越無腦 所以爛?
相反現在的ubuntu < 以前的ubuntu 因為現在的安裝越來越無腦 所以爛?
这篇手册我看过，里面的很多专业术语我看不懂，上学那会我最头疼的就是课本知识，于是就放弃了学好基础，用哪个学那个，用不到的时候就不学，不是不想学，而是悟性跟不上，学不下去