系統有三種基本硬體資源：CPU、memory 與 I/O，process 彼此競爭這些資源，kernel 負責公平分配。維運排查的底層工夫，就是知道系統變慢時該掏出哪一把工具、它到底在量什麼——與其執著調校，不如透過工具去理解 kernel 怎麼分配資源。
🧠 Intuition
TIP
排查按「問題長什麼樣」選工具：想看誰在吃 CPU 用 top（每秒更新、預設把最活躍的排最上）；想知道某 process 開了哪些檔案用 lsof；程式一啟動就崩、log 又沒線索時，用 strace 追 system call、ltrace 追 library call。
- top：
ps只給某一時間點的快照，top則是互動式、每秒更新；M依記憶體排序、P依 CPU 使用率（預設）、T依累計 CPU 時間、H才會顯示 thread。 - lsof：列出所有開啟的檔案及持有它們的 process；因為 Unix 一切皆檔案，它是排查最實用的工具之一，可
lsof -p pid針對單一 process。 - strace / ltrace：
strace印出 process 發出的所有 system call，開檔失敗會顯示精確錯誤（如-1 ENOENT）；ltrace追 shared library call，但無法用於 statically linked binaries。 - load average：
uptime給出過去 1／5／15 分鐘準備執行的 process 平均數量；接近 0 代表閒、接近 1 代表約一個 process 持續佔用 CPU，多核系統以核心數為滿載基準。 - cgroups：kernel 功能，把多個 process 編成一組、以群組為單位用 controller（cpu／memory／pids）限制資源；完全透過 filesystem 存取，通常掛在
/sys/fs/cgroup。
⚖️ Tradeoffs
看 load average vs 看 per-process 指標
- load average（
uptime）給的是全系統的宏觀水位——準備執行的 process 平均數量，一眼看出系統忙不忙。 - 但高 load average 不一定代表有問題：若 memory 和 I/O 資源充足，系統仍可能運作良好；真正該警覺的是 load 很高且明顯變慢，可能已在 thrash。
- 要定位到「是哪個 process」則要下沉到 per-process 工具：
pidstat -p pid以 vmstat 風格逐行輸出、不覆蓋前次結果，還能用-r（memory）、-d（disk）細看；iotop則以 TID 為單位顯示 I/O。
strace 精準定位 vs 觀測開銷與雜訊
- 當
top、lsof都幫不上忙（程式一啟動就崩），strace能逐條印出 system call 並顯示精確錯誤，特別適合追「缺失的檔案」這類 Unix 最常見問題。 - 代價是輸出量大：開頭的
execve()／brk()與中段大量 shared library 載入通常可忽略，真正有用的多在尾端的openat()／read()／close()。 ltrace追的 library call 數量遠多於 system call，務必過濾輸出；且對 statically linked binaries 無效。相較之下vmstat開銷極小，適合先快速看 swap／I/O／CPU 全貌。
🔑 Takeaways
- 依症狀選工具：吃 CPU 看
top、開啟的檔案看lsof、啟動即崩用strace／ltrace追呼叫；time拆解 user／sys／real 時間。 - 資源監控分層看：全系統用 load average、
vmstat、iostat（per-device），定位到單一 process 用pidstat、iotop（以 TID 顯示）；nice／renice可調排程優先權。 - cgroups 以群組為單位限制資源，透過
/sys/fs/cgroup的檔案操作；v1 每 controller 各一套、process 可跨多組，v2 一 process 一 cgroup、一 cgroup 多 controller，本書主推 v2。
No notes yet — jot your takeaways or Q&A here.