IT @ Jason Tools：自主開發的 IT 實用工具箱（四）

Jason Cheng 發布 2026.10.24 瀏覽 154 次

本文目錄

運作方式
在主機上收集資料
在瀏覽器分析
常見使用情境
注意事項
結論
參考資料

使用者說「系統每天下午都很慢」、客戶說「那台主機三不五時 CPU 衝高」，要查是哪一支程式造成的，最直接的方式是收集每個執行檔的 CPU、記憶體、磁碟 I/O 一段時間，再看趨勢。

問題是，要做到這件事，常見的做法是裝 agent 或 exporter、架 Prometheus 收資料、再架 Grafana、再做儀表板……為了查一次問題要搞這麼多東西，很多時候客戶的主機也不允許隨便裝軟體。所以我在 IT @ Jason Tools 做了執行檔效能檢視器：主機上只要放一支腳本跑一段時間，把產生的檔案拿回來，丟進瀏覽器就能分析，不用安裝任何軟體。

運作方式

整個流程只有兩段：

階段	在哪裡做	需要什麼
收集資料	要檢查的主機	Windows 內建的 PowerShell，或 Linux 內建的 bash
分析資料	你自己的電腦	瀏覽器開 it.jason.tools

和常見的監控方案比較：

項目	agent/exporter＋Prometheus＋Grafana	執行檔效能檢視器
主機上要裝的東西	agent 或 exporter 服務	無，一支腳本跑完就結束
要另外架的伺服器	Prometheus、Grafana	無
要設定的儀表板	要自己做或匯入	內建，載入檔案就有圖表
資料去向	存在監控伺服器	檔案在你手上，分析時也不會上傳
適合	長期監控、告警	臨時查問題、一次性的效能分析

長期監控、告警還是要靠正式的監控系統（我自己用 LibreNMS），但「這台主機最近到底是誰在吃資源」這種一次性的問題，用這個方式快很多。

在主機上收集資料

收集用的腳本放在 GitHub 的 it-scripts 專案裡，工具頁面上也有完整的下載與執行指令，可以直接複製。

Windows

以系統管理員身分開啟 PowerShell：

if (!(Test-Path C:\temp)) { New-Item -Path C:\temp -ItemType Directory }; cd C:\temp

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-RestMethod -Uri "https://raw.githubusercontent.com/jasoncheng7115/it-scripts/refs/heads/master/jt_procperf_analyzer/jt_procperf_analyzer.ps1" -OutFile "jt_procperf_analyzer.ps1"

powershell.exe -ExecutionPolicy Bypass -File .\jt_procperf_analyzer.ps1 -D 30 -I 15

-D 30：收集 30 分鐘
-I 15：每 15 秒取樣一次
-ExecutionPolicy Bypass：只對這一次執行放寬腳本限制，不會改到系統的執行原則

部分 Windows 11 用指令下載可能會被擋，也可以在瀏覽器直接下載 jt_procperf_analyzer.ps1 存到 C:\temp 再執行。完成後 CSV 檔就在 C:\temp。

Linux

建議用 root 執行，才能讀到所有程序的完整資訊：

cd /tmp
curl -O https://raw.githubusercontent.com/jasoncheng7115/it-scripts/refs/heads/master/jt_procperf_analyzer/jt_procperf_analyzer.sh
chmod +x jt_procperf_analyzer.sh
sudo ./jt_procperf_analyzer.sh -d 30 -i 15

Linux 版只用 /proc 與 awk、date 這些系統內建工具，連 bc 都不需要，一般發行版、容器、精簡的嵌入式系統都能執行。完成後會產生 process_metrics_YYYYMMDD_HHMMSS.csv。

常用參數

用途	Windows	Linux
收集時間（分鐘，預設 60）	`-D`	`-d`、`--duration`
取樣間隔（秒，預設 60）	`-I`	`-i`、`--interval`
輸出格式（CSV/JSON/TSV）	`-F`	`-f`、`--format`
輸出目錄	`-O`	`-o`、`--output`
只收集特定程序	`-IncludeProcesses`	`--include`
CPU 門檻（%）	`-MinimumCPU`	`--min-cpu`
記憶體門檻（MB）	`-MinimumMemoryMB`	`--min-memory`

例如只看 nginx 和 mysql：

sudo ./jt_procperf_analyzer.sh -d 30 -i 10 --include nginx --include mysql

注意：取樣間隔建議 20 秒以上。每次取樣都要讀取所有程序的資訊，間隔太短反而會讓腳本本身成為主機的負擔，影響你要觀察的結果。

邊收邊寫

腳本是每次取樣就寫入檔案，不是全部收完才寫。所以：

收集到一半可以先把檔案拿出來看
臨時要中斷，按 Ctrl + C，已經收集的資料不會遺失
長時間收集也不會在記憶體裡累積大量資料

在瀏覽器分析

打開 https://it.jason.tools/tools/process-perf-analyzer.html，把 CSV 檔拖進「資料來源」區塊，或直接貼上內容，按「開始分析」。

檔案不會上傳到任何地方，全部在瀏覽器分頁裡解析。效能資料裡有主機上的程序名稱、執行帳號，這點對客戶的主機特別重要。

想先看看效果，可以按「載入範例資料」，會產生一份 30 分鐘、每 10 秒取樣的範例。

總覽

分析完成後，上方會先顯示監控的程序數、CPU 最高的程序、記憶體最高的程序，以及資料來自哪種作業系統（依欄位自動判斷 Windows 或 Linux）。

程序篩選

左側的「程序篩選」列出這份資料裡所有的程序，每一列顯示該程序的最大 CPU 使用率。程序動輒上百個，全部畫上去圖表會糊成一片，可以用這幾種方式收斂：

搜尋：輸入程序名稱，例如 sql、java
CPU 使用率門檻：只列出最大 CPU 使用率超過指定百分比的程序，預設 0.1%，幾乎沒在動的程序直接排除
記憶體使用量門檻：只列出最大記憶體使用量超過指定 MB 的程序
磁碟 I/O 門檻：只列出最大磁碟 I/O 超過指定 MB 的程序

篩選完按「全選」，會選取所有符合條件的程序，「取消全選」則全部清除；也可以逐一勾選。清單上方會顯示目前選了幾個程序，圖表只畫勾選的程序。

程序篩選：依名稱搜尋，或依最大 CPU、記憶體、磁碟 I/O 設定門檻，勾選的程序才會畫在右側圖表

同一個執行檔有多個程序時（例如瀏覽器、服務主機），用上方的模式按鈕切換：

合併模式：依執行檔名稱加總，看整支程式的用量
分開模式：依 PID 分開，找出是其中哪一個程序在作怪

時間範圍

上方的「時間範圍選擇」是一條時間軸，拖曳左右兩個端點，所有圖表就會同步聚焦在中間那一段，右上角顯示目前選取的範圍。例如使用者說「下午兩點多最慢」，就把範圍拉到那半小時。

要指定精確的時間，可以用右上角的時間範圍按鈕輸入開始與結束時間；選「全部時間」則回到完整的收集期間。

趨勢圖表

選好程序後，會同時畫出八種趨勢圖：

圖表	用途
CPU 使用率	誰在吃 CPU、是持續高還是週期性衝高
記憶體使用量	是否持續成長（可能有記憶體流失）
磁碟 I/O 讀取、寫入	誰在大量讀寫磁碟
I/O 操作次數	小檔案大量讀寫造成的 IOPS 壓力
執行緒數量	執行緒不斷增加通常是程式有問題
控制代碼數量（Linux 為檔案描述元）	控制代碼只增不減，是資源流失的典型徵兆
分頁錯誤率	記憶體不足、頻繁換頁

所有圖表的時間軸是同步的，可以對照同一時間點 CPU、記憶體、磁碟 I/O 的變化，找出它們之間的關係。

最下方還有異常偵測與建議，例如 CPU 使用率超過 50% 的程序會特別標出來；以及每個程序的詳細資訊表。

常見使用情境

以下整理實際會用到的情況，每一種都附上建議的收集方式與要看的圖表。參數以 Windows 寫法為主，Linux 把 -D、-I 換成 -d、-i 即可；收集時間最長 1440 分鐘（24 小時）。

特定時段效能低落

使用者反應「每天下午兩點多系統特別慢」，但你去看的時候一切正常。這種情況要在問題時段之前就開始收集，把前後都涵蓋進去。

收集：例如 13:30 開始，-D 120 -I 20，收兩個小時
分析：用時間範圍只看 14:00 到 14:30，對照 CPU 使用率與磁碟 I/O 讀取、寫入
判讀：同一時間有哪支程式突然衝高，常見的是排程工作、防毒軟體全機掃描、備份軟體、Windows Update，或某個服務的批次作業

CPU 不定時衝高

監控系統告警 CPU 衝到 90%，等你登入時又降下來了，工作管理員或 top 什麼都看不到。

收集：拉長時間，例如 -D 480 -I 30，涵蓋一整個上班日
分析：看 CPU 使用率趨勢圖，是持續偏高，還是固定間隔出現的尖峰
判讀：週期性的尖峰多半是排程或定時同步；持續偏高才是程式本身的問題。尖峰很短暫時，取樣間隔要跟著縮短，否則會被平均掉

同名多程序的問題來源

Windows 上的 svchost、瀏覽器，Linux 上的 php-fpm、java、postgres，一個執行檔會有很多個程序，只看總量不知道是哪一個出問題。

收集：一般參數即可，例如 -D 60 -I 20
分析：先用合併模式確認是哪個執行檔用量最高，再切到分開模式依 PID 找出是其中哪一個程序
判讀：拿到 PID 後，再到主機上查它對應的服務或網站，例如 svchost 底下是哪個 Windows 服務、php-fpm 是哪個集區

磁碟 I/O 壅塞

系統反應遲鈍，但 CPU 和記憶體都不高；或是同一個儲存上的其他 VM 一起變慢。這種情況通常是某支程式在大量讀寫磁碟。

收集：在變慢的主機或 VM 裡收集，-D 60 -I 20
分析：看磁碟 I/O 讀取、寫入與 I/O 操作次數三張圖
判讀：讀寫量（MB）高代表大檔案的連續讀寫，例如備份、資料庫匯出；讀寫量不高但 I/O 操作次數很高，是大量小檔案讀寫，對 HDD 與共用儲存的影響通常更大，例如記錄檔寫太頻繁、暫存檔、索引

長時間執行後效能下降

某個服務跑幾天就越來越慢，重新啟動後才恢復，這是資源流失的典型症狀。

收集：時間要拉長，例如 -D 1440 -I 60，收一整天
分析：看記憶體使用量、控制代碼數量（Linux 為檔案描述元）、執行緒數量三張圖
判讀：正常的程式用量會上下起伏、維持在一個範圍；只增不減的那條線就是可疑對象。拿著這份圖表回報給軟體廠商，比單純說「它會越來越慢」有說服力得多

記憶體不足與頻繁換頁

主機記憶體吃緊時，作業系統會頻繁把資料換到磁碟，整台主機都會變慢。

收集：-D 60 -I 20
分析：看記憶體使用量與分頁錯誤率
判讀：分頁錯誤率長時間偏高的程序，就是最受記憶體不足影響、或是佔用最多記憶體的程序，可以作為加記憶體或調整服務設定的依據

變更前後比較

更新程式版本、調整設定、換防毒軟體，事後被問「是不是改了之後變慢」時，最好有數字可以對照。

收集：變更前、後各收一份，時段與參數要相同，例如都在上午 10 點、-D 60 -I 20
分析：兩份分別載入，看同一支程式的 CPU、記憶體與磁碟 I/O 趨勢
判讀：數字差異明顯才是變更造成的；差不多的話，就要往其他方向查

移轉前的資源評估

要把實體主機轉成 VM、或把服務搬到新主機時，配置多少 CPU 與記憶體常常只能用猜的。

收集：挑業務最忙的一天，-D 1440 -I 60
分析：看主要服務的 CPU 與記憶體尖峰，以及尖峰出現的時段
判讀：依實際尖峰加上餘裕來規劃，而不是照舊主機的規格原樣搬過去

無法安裝軟體的主機

客戶的正式主機不允許安裝 agent，或環境裡根本沒有監控系統，這是這個工具最主要的使用情境。

做法：把腳本與執行指令交給客戶的管理人員，執行完把 CSV 檔傳回來，你在自己的電腦用瀏覽器分析
好處：腳本只讀取系統資訊，跑完就結束，不會留下服務或排程；分析時資料也不會上傳到任何地方
注意：檔案裡有程序名稱、執行帳號、命令列，傳遞時要用安全的管道

只觀察特定服務

已經知道要看哪支程式，不需要收集全部程序，檔案也會小很多。

Windows：-IncludeProcesses "sqlservr","w3wp"
Linux：--include nginx --include mysql
也可以用 CPU、記憶體門檻（-MinimumCPU、-MinimumMemoryMB，Linux 為 --min-cpu、--min-memory）只記錄有在用資源的程序

Linux 版只用 /proc 與系統內建的 awk、date，容器或精簡的嵌入式系統也能執行，沒辦法裝監控套件的設備同樣適用。

問題與圖表對照

想回答的問題	建議收集方式	主要看的圖表
某個時段為什麼特別慢	涵蓋問題時段前後，`-I 20`	CPU、磁碟 I/O 讀取與寫入
誰讓 CPU 衝高	一整個上班日，`-I 30`	CPU
同名程序裡是哪一個	一般參數，分開模式	CPU、記憶體
誰在大量讀寫磁碟	變慢的主機或 VM 內，`-I 20`	磁碟 I/O 讀取、寫入、I/O 操作次數
有沒有資源流失	24 小時，`-I 60`	記憶體、控制代碼、執行緒
記憶體夠不夠	一般參數	記憶體、分頁錯誤率
變更後有沒有變慢	前後各一份，時段與參數相同	依變更內容挑選
新主機要配多少資源	最忙的一天，`-I 60`	CPU、記憶體