阿里雲服務器CPU滿載排查解決教程
對於運維和開發來說,最讓人半夜驚醒的報警短信,莫過於「您的雲服務器 ECS 實例系統 CPU 使用率已達到 100%」。
CPU 滿載意味著服務器的所有算力被瞬間榨乾,緊接著就是網站卡死、API 響應超時、數據庫連接爆滿,整個業務陷入癱瘓。 面對這種情況,新手往往手忙腳亂地去控制台重啟服務器。 重啟雖然能臨時救急,但如果沒找到根本原因,5 分鐘後 CPU 依然會重新飆到 100%。
今天這篇教程帶你像一個經驗豐富的老手一樣,冷靜、規範地排查並解決阿里雲服務器 CPU 滿載的問題。
第一階段:誤區排查與「看病」前的準備
在動手敲命令之前,先去
阿里雲控制台
看一眼監控大盤,確認一個關鍵指標:
基本型(T系列)的 CPU 積分
。
如果你買的是阿里雲的「突發性能型實例」(比如 t5、t6),這種服務器平時限制了基礎 CPU 算力(比如只給 20%)。 當你的業務超標時,會消耗「CPU 積分」來獲得全額算力。 一旦積分耗盡,伺服器就會被強行「限速」,表現出來就是 CPU 鎖死在某個低分位,系統卡得動彈不得。
解決辦法: 如果是突發性能型實例積分耗盡,要麼在控制台開啟「無性能約束模式」,要麼直接升級為「通用型」或「計算型」實例。
如果排除了硬件機型的限制,說明服務器內部確實有進程在瘋狂吃算力,我們必須登進系統開始「捉賊」。
第二階段:Linux 服務器 CPU 滿載排查全步驟
Linux 服務器是 CPU 爆表的高發區,大部分是因為壞代碼、高並發或者中了挖礦木馬。
第一步:找出「吃」算力的罪魁禍首(
頂端
命令)
使用 SSH 連上服務器,直接在終端輸入全宇宙通用的命令:
貝殼腳本
頂端
進入交互界面後,按下鍵盤上的大寫
P
(Shift + p),讓進程按照 CPU 使用率從高到低排序。
緊盯著前幾行,觀察以下三個核心字段:
PID: 進程的身份證號,後面殺進程全靠它。
USER: 哪個用戶啟動了這個進程。 如果是 www 或 nginx,大概率是代碼問題;如果是 root,且名字很奇怪,小心是木馬。
COMMAND: 進程的名字。
常見 COMMAND 嫌疑人分析:
Php-fpm、java、node、python:業務代碼在跑死循環,或者高並發下數據庫沒加索引導致硬扛。
mysql：資料庫正在執行複雜的關聯查詢、全表掃描。
kswapd0：系統記憶體不足了，正在瘋狂地將記憶體資料搬移到硬碟的 Swap 分區中，導致 CPU 也隨之急劇上升。
kinsing、sysrv、一串隨機亂碼：恭喜，伺服器被駭客入侵了，這是一種經典的挖礦木馬。
第二步：深度剝離，觀察進程內部在做什麼
如果發現是自己的程式碼（比如一個 Java 或 PHP 處理程序）把 CPU 吃滿了，光知道 PID 還不夠，還得知道是哪一行程式碼在作怪。
場景 A：Java 進程滿載排查（經典面試與實戰題）
假設滿載的 Java 進程 PID 是
1234
。
找出這個進程裡最耗 CPU 的執行緒號（TID）：Bashtop -Hp 1234。假設看到執行緒 1256 占了 90% 的 CPU。
把這個執行緒號轉換成十六進制（因為 Java 堆棧中使用的是十六進制）：Bashprintf "%x\n" 1256 #輸出結果假設為：4e8
使用 jstack 工具將 Java 的執行緒堆棧列印出來，再用 grep 抓取那個十六進制的執行緒號：Bashjstack 1234 | grep -A 20 "4e8"。螢幕上會直接顯示哪一個類、哪一行程式碼（例如 com.xx.service.impl.OrderServiceImpl.lambda$0(OrderServiceImpl.java:88）正在執行，死迴圈一目了然。
場景 B：MySQL 導致 CPU 爆滿
如果是
MySQL
進程排在第一。 立刻登錄資料庫執行：
SQL
顯示完整進程列表；
查看當前正在執行的 SQL 語句。 重點看
時間
（執行時間）最長的那些語句，如果看到大批
選擇中
狀態且沒有走索引的爛 SQL，直接通知開發加索引，或者讓 DBA 臨時把這條爛 SQL 殺掉。
第三步：果斷處置（如何優雅地收尾）
情況一：普通代碼死循環
如果影響到了生存，可以先用 PID 把進程殺掉，換取喘息時間：
貝殼腳本
kill -9 進程PID
然後趕緊去改代碼的 Bug。
情況二：中了挖礦木馬
黑客通常會掛定時任務，你單純
終止 -9
它是殺不死的，一秒鐘就會復活。
檢查定時任務：crontab -l，發現有奇怪的下載腳本，立刻用 cron
Tab -e 刪掉。
檢查殘留進程並殺死。
終極武器: 如果木馬大面積感染,最快且最乾淨的解決辦法是「利用快照恢復系統」,或者參考前文直接重裝系統。
第三階段:Windows 服務器 CPU 滿載排查全步驟
Windows 服務器相對直觀,直接通過圖形界面解決。
第一步:打開任務管理器
遠程桌面連接進服務器。
右鍵點擊底部任務欄,選擇 任務管理器。
點擊 CPU 列的表頭,讓它按使用率從高到低排序。
第二步:深入資源監視器
任務管理器有時候只能看到
W3wp.exe
(IIS 進程)或
Sqlservr.exe
很高,看不到細節。
在任務管理器底部,點擊 打開資源監視器。
切換到 CPU 選項卡。
在這裡你能看到每個進程的具體服務。 如果是 w3wp.exe 飆高,說明是 IIS 上的某個網站代碼有問題,可以通過 IIS 的「工作進程」查看具體是哪個網站的哪個 URL 在瘋狂消耗資源。
第四階段:預防勝於治療--如何防止 CPU 再次打滿?
把這次火滅掉之後,為了以後不半夜驚醒,你必須搭好三道防線:
在阿里雲控制台配置「CPU 報警規則」:進入 雲監控 -> 應用分組 或 主機監控。 給服務器加一條報警:當 CPU 使用率 >= 85% 持續 5 分鐘時,立刻往手機發短信/釘釘報警。 在它到 100% 之前提前介入。
數據庫加行「慢查詢日誌」:開啟 MySQL 的 slow_query_log,把執行時間超過 1 秒的 SQL 全部記錄下來。 每天去下發給開發優化,把隱患消滅在萌芽狀態。
代碼層設置超時機制:無論是外部 API 調用、複雜的循環還是多線程,都要設置最大超時時間。 別讓一個死循環無限期掛起消耗算力。
總結
排查 CPU 滿載就像抓小偷:
先用 top / 任務管理器鎖定嫌疑人(PID),再用 jstack / PROCESSLIST 拿到犯罪證據(哪行代碼/哪條SQL),最後果斷處置並加裝監控報警
。
遇到問題千萬別慌,按照標準流程層層剝離,任何讓系統卡死的爛代碼或木馬都無處遁形。
