服務器 CPU 100% 排查實戰：從代碼死循環到 CC 攻擊全鏈路分析

服務器 CPU 長期跑滿 (Load Average > 核心數 * 2) 會導致響應超時、健康檢查失敗、甚至觸發熔斷雪崩。本文提供標準化排查流程，覆蓋應用層 (代碼、配置)、系統層 (進程、線程、中斷)、網絡層 (流量異常)、安全層 (攻擊、木馬) 四大維度，並附帶實戰常用命令速查表。

標準化排查流程 (TOP-DOWN)

第一層：應用代碼與配置 (最高概率)

1. 線程池/連接池配置不當：Tomcat maxThreads、PHP-FPM pm.max_children、Go GOMAXPROCS 設置過大，超過 CPU 核心數導致上下文切換開銷激增。
   對策：CPU 密集型服務設置為核心數 (或核心數 +1)；I/O 密集型可適當放大 (2-4x 核心數)。
2. 代碼死循環 / 遞歸無出口 / 正則災難：如 while(true){}、Pattern.matches("^(a+)+$", "aaaaaaaaaaaaaaaaaaaaac") (灾難性回溯)。
   對策：jstack/gdb 分析熱點線程堆疊，定位業務代碼行號。
3. GC 頻繁 / 內存洩漏：JVM Full GC 佔用大量 CPU (STW 期間佔用 100% 核心)。
   對策：jstat -gcutil 觀察 GC 頻率，調整堆大小、新生代比例、升級閾值。

第二層：Web 服務器與中間件配置

1. Nginx/Apache Worker 數過多：worker_processes auto 在高核機器 (64C+) 可能啟動過多進程，上下文切換開銷大。
   對策：手動設置為物理核心數 (不含超線程)，如 16C 設置 16。
2. 緩存失效導致後端雪崩：Redis/Memcached 掛掉或熱 Key 失效，大量請求穿透至 DB/應用層。
   對策：檢查緩存命中率，啟用「緩存空值」、「互斥鎖重建」、「隨機過期時間」。

第三層：系統資源與異常進程

# 1. 定位高 CPU 進程
top -c  # 按 P 排序, 記錄 PID
htop    # 更直觀, 顯示線程

# 2. 分析進程線程
ps -mp PID -o THREAD,tid,time,comm | sort -k3 -r | head -20
# 找到佔用 CPU 最高的線程 TID (十進制)
printf "%x\n" TID  # 轉十六進制

# 3. 關聯代碼堆疊 (Java 示例)
jstack PID | grep -A 20 'tid_hex'
# 非 Java: gdb -p PID -ex "thread apply all bt" -batch

第四層：流量異常與攻擊排查

第五層：硬件與虛擬化層面

• CPU 降頻/過熱：cat /proc/cpuinfo | grep MHz 觀察主頻是否遠低於標稱；sensors 或 IPMI 查看溫度。
• 虛擬機 CPU Ready / Steal Time 高：top 觀察 st (steal time) 列，> 10% 表明宿主機超售嚴重，需遷移或投訴雲廠商。
• 中斷風暴：cat /proc/interrupts 觀察特定中斷號計數器飛速增長，常見於網卡多隊列未開啟 RPS/RFS、磁碟控制器故障。

Windows 環境排查差異

• 使用「資源監視器」 (resmon.exe) 或「進程探索者」 (Process Explorer) 定位高 CPU 線程。
• wmic process get ProcessId,Name,CommandLine 導出進程信息。
• 性能監視器 (perfmon.msc) 添加「處理器(_Total)\% 處理器時間」、「系統\處理器隊列長度」計數器。

應急處置 SOP

1. 止血：啟用 WAF/防火牆封禁攻擊 IP、重啟異常服務進程、限制並發連接數 (iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 100 -j REJECT)。
2. 保現場：cp /proc/PID/exe /tmp/suspicious_bin、netstat -antp > /tmp/netstat.log、lsof -p PID > /tmp/lsof.log。
3. 根因分析：代碼審計、配置優化、補丁修復、清理木馬、調整架構 (限流、降級、熔斷、削峰填谷)。
4. 復盤文檔：時間線、影響範圍、根因、修復措施、預防措施 (監控告警補齊、壓測驗證)。

CPU 100% 癥狀背後往往隱藏著架構缺陷或安全隱患，建立標準化排查體驗與應急預案，是保障業務連續性的核心能力。