用 htop 航行大數據海洋 — 船長的 CPU 與記憶體監控筆記

分類：Spark 航行日誌 / 系統監控基礎

前言

啟航前，船長一定會檢查引擎狀態與油箱油量。
對我們做 Spark 和大數據分析的人來說，啟航前的檢查，就是先了解 CPU 與記憶體 的情況，確保運算全速前進時，不會中途熄火。

這篇文章會用 htop 這個工具，帶你看懂 CPU、記憶體與系統負載的狀態，並用「廚房模式」的生活化比喻，讓你一眼就能判斷機器的健康度。

---

什麼是 htop？

htop 是 Linux 下的互動式系統監控工具，比傳統的 top 更直觀：

• 顏色化顯示 CPU / 記憶體使用情況

• 即時更新且可互動排序

• 支援同時顯示多核心的狀態（對多執行緒運算特別好用）

傳統的top

新的htop

htop 介面解讀 — 廚房模式對照表

---

1. CPU 條 → 爐台火力條

技術解釋：

• 每條代表一個邏輯核心

  • 1 到 8 代表這台機器有 8 個邏輯 CPU 核心（可能是 4 核心 + HT*，或 8 核心）

• 顏色代表狀態：

  • 綠色：使用者程式（例如 Spark 任務）

  • 紅色：系統核心（作業系統運作）

  • 藍色：低優先序工作

HT（Hyper-Threading）補充：

• Intel 的技術，讓一個實體核心模擬成兩個邏輯核心，提升多工效能。

• 例如 4 核心 + HT → 系統顯示 8 核心。

• 提升幅度通常 20~30%，視工作負載而定。

廚房比喻：

• 爐台的火力條顯示廚師在煮菜（綠）、廚房管理員在安排流程（紅）、助手在慢工出菜（藍）。

• HT 就像讓每個爐台同時能煮兩鍋菜，但速度提升有限。

---

2. Mem → 冰箱食材容量

技術解釋：

• 顯示記憶體總量與已使用量。

• 記憶體不足會啟用 Swap（速度慢）。

廚房比喻：

• 冰箱存放食材，如果快滿，就得跑去後巷倉庫拿貨，耗時耗力。

---

3. Swp → 後巷倉庫

技術解釋：

• 用磁碟模擬記憶體，速度遠比 RAM 慢。

• 0 代表沒用到，屬於健康狀態。

廚房比喻：

• 倉庫很遠，去一次浪費很多時間，最好不要動用。

---

4. Tasks → 廚師與助手人數

技術解釋：

• 顯示當前進程數與執行緒數。

• Spark 任務通常會啟動大量執行緒。

廚房比喻：

• 廚房有多少廚師（進程）與助手（執行緒）在忙，如果爐台不夠，就得排隊。

---

5. Load Average → 廚房排班壓力

技術解釋：

• 三個數字代表系統在不同時間範圍內的平均運算負載：

  • 第一個數字：1 分鐘平均負載（最近的瞬時壓力）

  • 第二個數字：5 分鐘平均負載（短期趨勢）

  • 第三個數字：15 分鐘平均負載（長期趨勢）

• 解讀方式

  • 有 8 個邏輯核心 → 數字 = 核心數 時代表 CPU 完全滿載

  • 如果 Load Average \> 核心數 → 表示有任務在等待 CPU（排隊中）

廚房比喻

• 如果廚房有 8 個爐台（核心），但排班表上同時有 15 位廚師要用爐台，就會有人等

---

6. Uptime → 廚房營業時間

技術解釋：

• 系統自開機到現在的運行時間。

廚房比喻：

• 餐廳今天開門到現在的營業時長。

---

Spark 實戰例子 — CPU 滿載觀察

這張圖顯示的是 Spark 執行時 CPU 幾乎被「吃滿」的狀況：

1. CPU 使用率

   • 1 到 8 代表這台機器有 8 個邏輯 CPU 核心（可能是 4 核心 + HT*，或 8 核心）。

   • 幾乎每個核心都在 98%~99% 使用率（紅色表示接近滿載），這說明 Spark 任務是 CPU 密集型的。

   • 廚房比喻：廚房有 8 個爐台（邏輯核心），幾乎每個爐台火力都全開在煮菜，表示這場宴會是非常耗火力的工作。

2. 記憶體（Mem/Memory）

   • 19.7G / 30.7G 表示已使用約 64% 記憶體，還有一些剩餘空間，但 Spark 任務大多會吃更多記憶體，如果 dataset 很大，可能會觸發 GC 或 spill 到磁碟。

   • 廚房比喻：冰箱容量是 30.7G，現在放了約 64% 的食材，還有空間，但如果來更多客人（大 dataset），可能要趕緊清冰箱或暫時把食材放到其他地方（磁碟）。

3. Swap

   • 0K/0K 表示沒有啟用 Swap（或 Swap 空間為 0），所以記憶體不足時不會自動用磁碟緩衝，會直接 OOM。

   • 廚房比喻：後巷倉庫完全沒啟用，一旦冰箱爆滿，就沒有臨時倉庫可用，廚房可能直接停擺（OOM）。

4. Load Average*

   • 17.82（1 分鐘）、12.72（5 分鐘）、7.33（15 分鐘）

     • 1 分鐘：17.82 → 幾乎是 2 倍於核心數 (8)，CPU 過載嚴重，很多任務在等

     • 5 分鐘：12.72 → 最近幾分鐘也一直是高負載

     • 15 分鐘：7.33 → 長期負載接近滿載，但還沒到排隊很多的程度

   • 在 8 核 CPU 上，Load Average 如果超過 8，就代表系統任務排隊中，CPU 壓力很大。現在 1 分鐘的 load 是 15.52，表示有不少任務在等 CPU。

   • 廚房比喻

     • 1 分鐘：17.82

       • 就像廚房只有 8 個爐台，但這一分鐘突然有 17 位廚師同時要用爐台，超過兩倍滿載，廚師們只能在旁邊乾等，現場非常擁擠。

     • 5 分鐘：12.72

       • 過去 5 分鐘，廚房一直保持「人比爐台多」的狀態，雖然沒有像 1 分鐘前那麼誇張，但依舊有不少廚師在排隊。

     • 15 分鐘：7.33

       • 長期來看，廚房幾乎一直在滿載工作（爐台幾乎沒空過），但廚師排隊的情況沒有短期那麼嚴重，算是穩定的高壓運作。

5. 任務數

   • Tasks: 12, 346 thr; 5 running

     • 12 個進程（process），總共有 346 個執行緒（threads），其中有 5 個在同時執行。Spark Executor 通常會開很多執行緒處理 task。

     • 廚房比喻：廚房裡有 12 位廚師（進程）和 346 位助手（執行緒）忙著各種工作，其中 5 位廚師正在爐台上全力煮菜。

小結：
此時的 Spark Job 是 CPU 滿載 + 高 Load 的狀態，說明計算很密集，可能需要：

• 調整 Spark 的 executor-cores 或 num-executors，讓資源利用更均衡

• 如果 CPU 長期滿載導致任務等待，可考慮加機器或改用更快的演算法

• 留意記憶體使用，避免溢出

---

CPU 長期 100% 的影響與對策

影響：

1. 互動延遲增加（SSH、系統回應變慢）

2. 溫度過高可能降頻（Thermal Throttling）

3. Spark 任務排隊變長

對策：

• 監控溫度（<85°C）

• 留 1~2 核心給系統

• 適度調整 executor-cores、num-executors

• 長任務建議 checkpoint、中繼輸出

• 使用 tmux/screen 避免斷線中斷任務

---

航行提醒

如果沒有其他重要任務，CPU 長時間 100% 是可以的，只要：

• 溫度安全

• 記憶體不逼頂（或有適當 Swap）

• 磁碟空間與 I/O 正常

• 系統可互動

---

小結

在啟航之前，船長必須清楚掌握廚房與引擎的即時狀態。
透過 htop，我們能：

• 看見爐台（CPU）是否滿載或閒置

• 判斷冰箱（記憶體）是否還有足夠食材

• 確認後巷倉庫（Swap）有沒有被動用

• 觀察廚房排班（Load Average）是否過於擁擠

這些觀察讓我們在跑 Spark 或任何大數據任務時，能提前發現資源瓶頸，避免「航行到一半停船」的尷尬。

下一篇，我們會走進船艙的食材倉庫，用 vmstat 檢查「食材供應」——也就是硬碟與 I/O 狀態，確保船隊在大數據海洋上能長時間高速航行。