VS Code Remote-SSH 把我的伺服器燒到 96°C

我那台家用伺服器上跑著三十幾個容器:部落格、NAS 面板、監控、幾個自架服務。除此之外我平常也直接用 VS Code Remote-SSH 連進去寫程式,工作區 36 GB、四十萬個檔案。

七月中某個下午,它被燒到失去回應。

查了三天,兇手是編輯器,不是那三十幾個容器裡的任何一個。

症狀:溫度釘在 90°C 撐了四十分鐘#

我在追一個更早的斷電問題時,順手加了一支每分鐘記一次 CPU 溫度和 load 的腳本。那支腳本記到了這個:

15:12  cpu=90.1C  load=8.65
15:22  cpu=90.0C  load=32.53
15:31  cpu=90.0C  load=84.42
15:43  cpu=90.0C  load=156.54
15:50  cpu=90.0C  load=196.01   ← cron 已經排不進去了

溫度死死釘在 90°C,load 從 8 一路衝到 196,連每分鐘一次的 cron 都排不進去,撐了四十分鐘之後整台失去回應。

死前的 journal 每四秒噴一次:

amdgpu 0000:79:00.0: amdgpu: SMU: I'm not done with your previous command

SMU 是晶片裡管電源和溫度的那顆微控制器。連它都調度不出來,代表 CPU 已經忙到底了。

電力可以先排除:我那台接著 UPS,而 UPS 全程 OL、市電穩、電池滿。這不是斷電。

先講結論#

三個兇手,全部來自 VS Code Remote-SSH 那一包:

下面是怎麼查出來的。

這件事難查,是因為線索會騙你#

溫度不是突然爆的,是一路爬上來的:

07-16 完全沒事,07-17 開始就變了。有東西在 07-17 那天加進來,而且從此沒走。

問題是接下來三條線索,每一條看起來都很有說服力,而每一條都是錯的。

陷阱一:感測器在說謊#

當下讀到的是這組數字:

Tctl: 94.6°C   PPT: 5-22W   load: 10-13

8700G 在 5 到 22W(等於閒置)應該是 45 到 55°C,而這裡是 94°C。功耗那麼低卻那麼燙,結論只有一個方向:熱傳不出去,散熱膏乾了或散熱器沒壓緊。時間點還配得上——七月初我為了追斷電問題開過機殼,很可能那時候碰掉了 CPU 風扇的線。

所以當時的判斷是要重上散熱膏。我沒有動手,純粹是懶——要拆的是一顆利民 PS120 EVO,雙塔的東西拆下來再裝回去很麻煩,而且還得去翻散熱膏放在哪。

結果沒動手反而是對的。重開機之後,同樣的機器、同樣的散熱器:

而且是帶著負載(load 12、容器全部在跑)還維持 55°C。

陷阱二:重開機就好了#

重開之後回頭看行程表,抓到一隻吃了好幾天 CPU 的:

msedge   395% CPU   ← 四顆核心

因果鏈當場就成立了:Edge 某個分頁跑飛 → CPU 長期滿載 → 頂到 Tjmax 狂降頻 → 工作積壓 → load 8、32、84、196 → SMU 被搞當 → 系統卡死。而且重開機把 Edge 清掉之後一切正常,看起來像驗證過了。

但我後來自己進去看過。用 RustDesk 連進 server,沒有開 Edge,CPU 使用率也只有 30 到 50%。

如果沒開 Edge 也燙,那 Edge 就不是主因。「重開機就好了」只能證明兇手不是常駐服務,不能證明兇手是誰——把它當成因果驗證,是我在這件事上最接近走錯路的一次。

陷阱三:CPU 只有 30 到 50%,看起來不像過熱#

這條最反直覺,而它其實是答案。後面用 sar 拆開來看。

怎麼追一個已經結束的事件#

事件過去了,行程也死了,而我不想等它重現一次再抓。好在有兩個東西替我留了歷史。

07-16(沒事)   %user  7%   %system  3%   %idle 87%
07-20(94°C)   %user 46%   %system 18%   %idle 32%   runq-sz 20-24   blocked 0

差值        熱窗        靜窗   app
+829.3     834.7        5.4   sshd     ← 8.3 顆核心
  +5.0      45.5       40.4   dockerd
  +4.7       9.0        4.3   rustdesk

sshd 從 5.4% 暴衝到 834.7%,但這不代表 SSH 服務本身有問題。apps.plugin 會把認不出名字的行程歸到它父行程的群組,而我是用 VS Code Remote-SSH 連進去的:

sshd
└─ code-server
   ├─ bootstrap-fork --type=fileWatcher
   └─ bootstrap-fork --type=extensionHost
      ├─ tsserver.js ×2
      ├─ typingsInstaller.js
      ├─ jsonServerMain
      └─ claude ×2

整包 VS Code Remote-SSH 在 netdata 眼裡全部算 sshd。 依使用者分組看也對得上:我的帳號從 74% 變成 928.7%,root 幾乎沒動。時間軸也吻合:

這兩支我都是很久以前隨手裝的,平常完全不會去看。這次能不等重現就把事件還原出來,靠的就是它們——sysstat 留 CPU 組成,netdata 的 apps.plugin 留 per-process 歷史。

兇手一:rust-analyzer 無限重跑 cargo check#

縮到 VS Code 這包之後,直接翻它自己的 log。最大的那個檔案是 rust-analyzer,裡面滿滿都是:

ERROR Flycheck failed to run: cargo check --workspace
error: failed to run custom build command for `soup3-sys`
error: failed to run custom build command for `javascriptcore-rs-sys`
error: failed to run custom build command for `gobject-sys` / `glib-sys` / `gio-sys`

完整的指令是:

cargo check --workspace --keep-going --all-targets \
  --manifest-path ~/Server/tauri-plugin-sidecar/Cargo.toml

那是一個 Tauri 外掛專案,而 Tauri 在 Linux 上是靠系統的 GTK 和 WebKit 畫視窗的。編譯的時候,那些 *-sys crate 會去系統上找對應函式庫的開發檔案。

問題是這台是無頭伺服器,從來沒裝過桌面環境,所以那些東西一個都不在。log 裡缺的是這些:

而同一組失敗在 log 裡重複了三十五次——那就是它重試的次數。

換句話說,這個 cargo check 不是編很久,是永遠編不完:每一輪都在同一個地方倒下,倒完再從頭來。迴圈是這樣成立的:

這也解釋了兩件先前講不通的事:為什麼只有 07-17 之後才發生(那天開始弄那個 Tauri 專案),以及為什麼一重開機就好(VS Code session 沒了,rust-analyzer 也跟著沒了)。

怎麼修#

根治是裝那些系統依賴,或者不要在伺服器上開那個專案。但更重要的是加一道「就算再迴圈也燒不掉機器」的上限:

# ~/.cargo/config.toml
[build]
jobs = 6

// rust-analyzer:不要編 test/bench/example,並限制執行緒
{
  "rust-analyzer.check.allTargets": false,
  "rust-analyzer.numThreads": 4
}

jobs 那條是唯一能保證上限的東西,其他都是治標。

順帶一提,files.watcherExclude 我原本就設得不錯,已經排除了大型資料夾。所以檔案監看不是這次的問題,純粹是 cargo——這點值得講,因為「VS Code 很吃資源」的討論裡,檔案監看常常被當成唯一嫌疑。

兇手二:Foam 擴充讓 ripgrep 開出兩百多個行程#

以為結束了,但幾天後 CPU 又開始上上下下。連續採樣 rg 的行程數量:

16 → 36 → 6 → 5 → 15 → ... → 245

追來源,每一個都是這種指紋:

rg (--files ... .foam ...)
   └── PID 1220855  = VS Code 剛才自動重開的新 ext host

是 Foam 在週期性地叫 rg --files 掃整個工作區。而我的工作區是這個規模:

停用之後 rg 歸零,溫度從 90°C 掉回 69°C。

這個症狀不是我獨有的。VS Code 有 rg 吃到 900% CPU 和 rg 長期高 CPU 的 issue,Cursor 社群也有一串 Cursor spawns hundreds of rg processes,症狀跟我的 245 個幾乎一樣。

那些討論的共同點是沒有人指出根因,底下多半在猜是不是 ripgrep 自己變慢了。但 rg 沒壞,它只是被一遍又一遍叫起來。在燒 CPU 的是 rg,一直按下去的手是別的東西——這類問題要找的是呼叫者,不是被呼叫的那支程式。

兇手三:RustDesk(其實只是雜訊)#

順手做了一次三十秒的行程側錄,把新冒出來的行程全部記下來:

11× sh   ← 由 rustdesk 開的
 7× ps   ← 由 rustdesk 開的

RustDesk 1.3.1 每秒 fork 一到兩個 sh 去跑 ps aux,用來管理自己的子行程和偵測使用者 session。四天累積燒掉十九小時 CPU,沒有任何人連線也照跑,重啟也沒用。

換算成整機是十六核裡的 1.5%。這個量級不足以把 CPU 煮沸,我需要它來遠端進機器看畫面,所以留著。寫出來只是因為它在 netdata 的差值表裡排第三,而排除它花掉的時間比它值得。

事後補的兩道保險#

溫度上限壓到 85°C#

我進了一次 BIOS,把 CPU 的溫度上限從預設的 95°C 附近壓到 85°C。

理由不是散熱不夠,而是這次的事故已經證明「某個東西無限迴圈把全核吃滿」是會發生的。溫度上限的作用是在那種情況下提早降頻:機器會變慢,但不會全核滿轉硬撐在 90°C 以上四十分鐘。

設定位置在 PBO 底下的 Thermal Throttle Limit。正常使用完全感覺不到差別,因為平常根本碰不到 85°C——處理完之後量到的基準是溫度 72.6°C、尖峰 83°C,功耗平均 40W、尖峰 64W(上限約 88W),全核 4.6GHz、單核 4.9GHz,一切正常。

再往下還可以做 Curve Optimizer 降壓,更涼更省而效能不掉。但這是存資料的機器,降壓不穩的表現是隨機當機和 segfault,求穩優先於求極致,這條我不做。

遠端開發改了用法#

修完之後我還是調整了工作方式,因為這兩個兇手都不是意外,是遠端開發這個架構的必然結果——語言伺服器、檔案索引、擴充套件、搜尋,全部都跑在那台散熱餘裕遠不如桌機的伺服器上。工作區越大越吃,而我的是 36 GB、四十萬個檔案,正好是最壞的組合。

現在的分法是:在家走內網用 VS Code Remote-SSH,人就在機器旁邊,真的燒起來我看得到也關得掉;在外面長時間連就換 Zed,因為上面那三個兇手全都是「連著連著它自己燒起來」的類型,人不在現場正是最糟的狀況。