騰訊雲帳號充值 騰訊雲 CVM 實例開啟 Swap 交換分區後系統極度卡頓排查

問題現象：不是單純變慢，而是整台機器像被拖住

很多人第一次在騰訊雲 CVM 上開啟 Swap，原本是想給系統多一點緩衝，避免內存一緊就直接 OOM。結果很快發現，機器不但沒有變穩，反而開始出現極度卡頓：SSH 登入慢、命令執行延遲明顯、top 裡的 load average 飆高，甚至連簡單的 ls 都要等半天。

這類問題最容易讓人誤判。表面上看，像是『開了 Swap 之後系統就變慢了』，但真正的原因通常不是 Swap 本身，而是系統已經進入了內存壓力區間，Swap 只是把問題從『直接報錯』變成『持續抖動』。只要一旦頻繁換頁，磁碟 I/O 會被打滿，CPU 也會花大量時間等待，最終整台機器就會像卡住一樣。

騰訊雲帳號充值 所以，排查這類問題不能只看『有沒有 Swap』，而要看『Swap 是否被大量使用』『換頁是否頻繁』『磁碟是否已經頂住』『是什麼進程在吞內存』。這四件事只要有一件沒看清，結論就很容易跑偏。

先確認：Swap 開了不等於問題解決了

在 Linux 裡，Swap 的作用是把暫時不用的內存頁面換到磁碟上，給物理內存騰空間。這個設計本來沒錯，但它有一個前提：換頁不要太頻繁，磁碟性能也要撐得住。否則，原本應該是『後備空間』的 Swap，會變成系統的性能瓶頸。

在 CVM 上，尤其是中小規格實例，內存和系統盤往往都不算寬裕。如果把 Swap 直接放在比較慢的雲盤上，再遇上內存不足的業務高峰，就很容易出現典型的『抖一下就卡死』。這種卡頓不是偶發的，而是持續性的：內存越緊，換頁越多；換頁越多，磁碟越忙；磁碟越忙，整體響應越差；響應越差，業務堆積得越嚴重。

第一步：確認 Swap 狀態

先不要急著調參，先把當前狀態看清楚。常用命令如下：

free -h
swapon --show
cat /proc/swaps
cat /proc/meminfo | grep -E 'MemAvailable|SwapTotal|SwapFree'

如果你看到 Swap 已經啟用，但可用內存很低，甚至 Swap 已經用掉不少，那就要高度懷疑系統正在靠換頁硬撐。這時候，卡頓通常不是偶然，而是必然。

第二步：看是不是在頻繁換入換出

真正能說明問題的，不是『用了多少 Swap』，而是『換頁是否持續發生』。這裡最實用的是 vmstat。

vmstat 1

重點看 si 和 so 兩列。si 代表 swap in，so 代表 swap out。如果這兩個值長時間不為 0，甚至一直在跳，說明系統正在不停把內存頁換進換出。這種情況下，哪怕 Swap 總量不大，也足以把機器拖慢。

第三步：看磁碟 I/O 是否已經爆了

Swap 一旦開始頻繁工作，第一個被打穿的往往就是磁碟。尤其是 CVM 這種雲上環境，磁碟性能受雲盤類型、隊列深度、整體佈局影響很大。可以用 iostat 觀察：

iostat -x 1

如果你看到某塊盤的 util 接近 100%，await 很高，說明磁碟已經忙到排隊。這時候系統卡頓就很容易理解了：Swap 讀寫本來就不是順序大文件，而是大量零碎頁面操作，對 I/O 延遲極其敏感。一旦盤慢，整個系統的反應都會被拖下來。

幾個最常見的根因

1. 內存本來就不夠，Swap 只是把問題延後

這是最常見，也最容易被忽略的原因。很多服務在平時看起來還行，但一到流量高峰、批處理、報表任務、緩存膨脹、或者定時任務集中觸發時，內存就會突然吃緊。這時候開 Swap 雖然能避免立刻 OOM，但如果業務本身的常駐內存超過了機器能承受的範圍，Swap 只會讓系統在『活著』和『能用』之間來回掙扎。

簡單說，Swap 是急救藥，不是補品。它能保命，但不能治病。

2. swappiness 參數設得太激進

Linux 會根據 swappiness 決定多積極地使用 Swap。這個值越高，系統越傾向把匿名頁面換出去。對一些伺服器場景來說，預設值並不一定合適，尤其是對延遲敏感的服務。當 swappiness 偏高時，系統可能在內存還沒真的緊到必須換頁之前，就開始積極使用 Swap，結果就是明明還有可用內存，卻已經先進入了高 I/O 狀態。

這種問題的特徵是：內存看起來不是最糟，卻依然很卡。這時候就要懷疑不是『內存徹底不夠』，而是『系統太早把頁面趕去磁碟了』。

3. Swap 放在慢盤上，或者和業務盤搶資源

有些人會把 Swap 放在系統盤，或者放在一塊本來就很忙的數據盤上。這樣一來，只要業務本身有讀寫，Swap 再一加入，就等於把兩種不同性質的 I/O 疊在一起。結果不是單純變慢，而是相互搶資源，延遲被放大。

如果你的 CVM 上跑的是數據庫、消息隊列、搜索引擎，或者任何對磁碟延遲敏感的應用，這種做法尤其危險。因為 Swap 的 I/O 特性很差，和業務 I/O 混在一起，經常會把整體性能拖垮。

4. 應用程序本身有內存泄漏或配置不合理

很多人第一反應是調 Linux 參數，卻忘了最根本的問題可能出在應用上。比如 Java 進程堆設太大、容器沒有限制、緩存庫無上限增長、Python 任務一次性把大對象塞進內存，或者某個後台進程長期泄漏。這些情況下，Swap 只是替應用錯誤買單，最後還是會被拖死。

如果某個進程的 RSS 一直增長，而且沒有回落，基本就不能只看系統層，必須回到業務代碼和部署配置去查。

5. 雲主機性能邊界被碰到了

騰訊雲帳號充值 在雲上，還有一個容易被低估的因素：實例規格和磁碟性能不是無限的。特別是低配 CVM，本身可分配的 CPU、內存、磁碟性能都有限。一旦工作負載超過了實例能承受的範圍，哪怕只是一點點額外的 Swap 壓力，也可能被放大成明顯的卡頓。

這種情況下，不是調一兩個參數就能徹底解決的。你需要重新評估實例規格是否足夠，而不是盲目加大 Swap。

實戰排查：按這個順序看，基本不容易走偏

第一步：先看整體壓力

先用 top 或 uptime 看負載，再結合 free -h 和 vmstat 判斷是不是內存壓力導致的系統抖動。如果 load 很高，wa 也高，說明進程大部分時間都在等 I/O。這時候再去看 Swap，通常八九不離十。

top
uptime
free -h
vmstat 1

騰訊雲帳號充值 第二步：找出吃內存的進程

騰訊雲帳號充值 有時候 Swap 不是全局性問題，而是某個進程特別能吃。這時候要把吃內存最多的進程找出來。

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head

如果是容器環境，還要看容器的內存限制是否設得太小。很多卡頓其實不是主機內存不夠，而是容器被擠壓得太厲害，導致容器內進程頻繁換頁。

第三步：看是否有異常殺進程或 OOM 跡象

有些機器在卡頓前，內核已經記錄了 OOM 相關信息。查看 dmesg 或系統日誌，能直接看到是否有進程被殺、是否有內存分配失敗、是否有大規模回收。

dmesg | tail -n 50

如果你看到 OOM 或 reclaim 很頻繁，那說明問題根子還在內存設計，而不是單純的系統參數。

第四步：確認 Swap 位置和類型

不是所有 Swap 都一樣。如果你用的是 swapfile，要確認它所在的文件系統和磁碟性能；如果是 swap 分區，要確認是不是和高負載數據放在一起。對延遲敏感的 CVM，Swap 的位置非常關鍵。它越接近快盤，換頁時的損失就越小；它越接近慢盤，卡頓就越明顯。

修復思路：不是一味關掉，而是把系統拉回合理區間

把 swappiness 調低

如果你的業務對延遲很敏感，通常不建議讓系統太積極使用 Swap。可以先把 swappiness 調低到 10，甚至更低，再觀察一段時間的 I/O 和響應情況。

echo 10 | sudo tee /proc/sys/vm/swappiness

如果調低後卡頓明顯緩解，說明問題的一部分確實來自過早換頁。要注意，這不是永久配置，重啟後會失效，需要再寫入 sysctl 配置文件。

控制 Swap 規模，不要把它當成第二塊內存

有些人一想到補救，就直接把 Swap 開得很大。其實這不是好習慣。Swap 太大，會讓人產生錯覺，以為內存問題已經被解決；但一旦真的用上，就會把性能拖得更慘。更合理的做法是把它當成『緩衝區』，而不是『可長期依賴的內存擴容』。

如果業務確實需要更多內存，那就應該升配，而不是把大量壓力轉移到磁碟。

把 Swap 放到更合適的磁碟上

如果你必須使用 Swap，盡量讓它放在性能更好的磁碟上，並避開和核心業務爭搶同一條 I/O 路徑。對雲主機來說，這件事往往比想像中更重要。很多性能問題不是 CPU 不夠，也不是程序慢，而是磁碟排隊太嚴重。

騰訊雲帳號充值 從源頭減少內存壓力

最有效的方式，永遠是讓程序少吃內存。可以從這幾個方向入手：

• 排查內存泄漏，尤其是長時間運行的後台服務。
• 限制容器內存上限，避免單個容器把整台機器拖垮。
• 調整 JVM、Python、Node 等運行時的內存配置。
• 減少一次性加載大數據到內存的設計。
• 把大批量任務拆分成小批次，降低峰值壓力。

這些改動雖然不花哨，但往往比任何參數調整都更有效。

如何判斷是不是應該保留 Swap

對很多 CVM 來說，問題不是『要不要有 Swap』，而是『要不要讓它參與正常運算』。如果你的服務屬於以下類型，通常可以保留很小的 Swap 作為保險：

• 偶爾有內存尖峰，但平時很穩定。
• 允許短暫緩衝，不要求極低延遲。
• 實例內存比較充足，只是防止偶發 OOM。

但如果你的業務屬於這類，則要非常謹慎：

• 數據庫、搜索引擎、消息隊列。
• 高並發 Web 服務。
• 對響應延遲非常敏感的 API。

這些場景裡，Swap 一旦被大量使用，體感上的退化通常會非常明顯。與其寄希望於 Swap，不如從實例規格、內存模型和應用架構上解決問題。

最後的判斷標準：看三個指標就夠了

如果你在騰訊雲 CVM 上遇到開啟 Swap 後的極度卡頓，最簡單的判斷方法其實只有三個：

• si 和 so 是否持續不為 0：如果是，說明系統一直在換頁。
• iowait 是否偏高：如果高，說明卡頓和磁碟 I/O 強相關。
• 某個進程的內存是否異常增長：如果有，問題多半在應用層。

這三個指標連起來看，基本就能判斷大方向。很多現場排障之所以繞遠路，就是因為一上來只盯著 Swap 是否已開啟，卻沒有看它是否真的在工作、工作到了什麼程度、代價是不是已經超出系統承受範圍。

結語：Swap 不是洪水猛獸，但把它當救命稻草就容易出事

騰訊雲 CVM 開啟 Swap 後出現嚴重卡頓，真正的關鍵不在『是否開了 Swap』，而在『系統為什麼需要頻繁用到 Swap』。如果內存壓力沒解決，Swap 只會把問題從 OOM 變成高延遲；如果磁碟性能不夠，Swap 只會放大卡頓；如果應用本身持續吃內存，再多的 Swap 也只是暫時緩兵之計。

所以，排查這類問題最有效的思路，是先看整體資源壓力，再看換頁和磁碟，再回到進程和應用。當你把這條鏈路串起來，就會發現很多『開了 Swap 就很卡』的現象，其實早就埋下了伏筆。真正要修的，不是 Swap 本身，而是把系統拉回一個更健康的資源使用區間。