Mac 為什麼變慢,以及如何診斷
Mac 變慢,通常是某項資源在卡頓發生時已經飽和:CPU、記憶體、磁碟空間、磁碟讀寫、散熱或網路服務。等問題消失後再看一張狀態截圖,很難找到原因。
別把閒置記憶體當成目標
macOS 會主動用閒置記憶體快取近期檔案,需要空間時再釋放。可用記憶體很少,不等於記憶體不足。
系統還會壓縮不活躍的記憶體頁面,減少寫入較慢交換空間的次數。查看計數:
vm_stat
輸出以頁面為單位,頁面大小在頂部附近。重點不是 Pages free,而是記憶體壓力和變化速度。Swapins、Swapouts 是開機以來的累計值,數字大不代表此刻有問題。在卡頓期間執行兩次,觀察增量,也可以直接看「活動監視器」記憶體頁。
Apple 的記憶體說明把記憶體壓力分為綠色、黃色和紅色,壓力圖、交換空間趨勢和應用程式列表放在一起,比閒置記憶體更有參考價值。
找到正在飽和的資源
在卡頓發生時,依序檢查:
- CPU: 執行
top -o cpu,或在「活動監視器」CPU 頁排序。%CPU 按核心計算,超過 100% 只表示行程同時使用多個核心。建置和輸出時很正常,閒置應用程式長期如此才異常 - 記憶體: 看記憶體壓力和交換空間是否持續上升
- 磁碟容量: 執行
df -h /。APFS 需要空間保存交換資料和暫存檔案,磁碟接近用盡會妨礙更新和大型任務。沒有通用的安全百分比,要看剩餘容量是否滿足目前任務。容量不足時,先找出大檔案,再安全釋放空間 - 磁碟讀寫: 在「活動監視器」磁碟頁按讀取或寫入位元組排序,並觀察卡頓時的曲線。
iostat -w 1提供即時命令列視圖。同步、備份、建置和故障外接磁碟,都可能在空間充足時造成延遲 - 散熱: 見後文
- 網路與服務: 如果只有一款雲端應用程式變慢,本機應用程式仍流暢,先檢查它的網路活動和服務狀態
CPU 被某個行程占滿
top -o cpu 會把高占用行程放在頂部。常見原因是應用程式卡住、同步用戶端重複掃描,或輔助程式陷入迴圈。確認可以安全結束後,正常退出它。
行程幾秒後自動重新啟動,說明背後可能有 launchd 任務或登入項目,只結束行程不會持久生效。系統行程也不能按普通應用程式處理,例如 kernel_task 升高常常是在晶片過熱時限制其他任務繼續發熱,它更像散熱訊號。
散熱降頻
Mac 過熱時會降低晶片頻率,高負載任務因此變慢。查看系統記錄的散熱狀態:
pmset -g therm
採集一次功耗與散熱壓力樣本:
sudo powermetrics --samplers thermal,cpu_power -n 1
相同負載下的變化比單個溫度更可靠,因為不同機型沒有統一上限。瓶頸確實來自降頻時,方向通常是減少負載、改善通風或檢查硬體,清快取不會改變散熱,無風扇 Mac 也會降頻,MacBook 風扇為什麼很響介紹了更完整的背景。
Spotlight 和登入項目
macOS 更新、遷移或大量移動檔案後,Spotlight 可能重新索引。mdutil -s / 只能說明索引是否開啟,不能證明正在重建。持續的 mds 或 mdworker CPU、磁碟讀寫和 Spotlight 進度一起出現,才說明索引正在工作。所需時間取決於資料量、磁碟速度、權限和檔案是否持續變化,沒有固定的一小時承諾。
再檢查「系統設定 > 一般 > 登入項目與延伸功能」。登入時打開的應用程式和允許背景執行的軟體可能使用 Service Management、launchd、延伸功能或輔助程式。一次只關閉一個身分明確的項目,並確認所屬應用程式仍能正常工作。
即時監控如何保持輕量
Mole 的開源命令列版 cmd/status 和原生 Mac 應用程式使用不同採集器,但都會把快速指標與慢速資訊分開處理。
命令列版解析 vm_stat 的檔案快取頁數,並讀取 memory_pressure,不會根據閒置位元組自行推算壓力。原生應用程式直接透過 host_statistics64 取得 VM 計數,透過 kern.memorystatus_vm_pressure_level 讀取壓力等級。
CPU、記憶體和網路等低成本指標約每秒更新。行程、GPU 和磁碟資訊降低頻率,硬體與裝置探測使用更長快取,趨勢線只保留近期樣本,以減少監控本身的負擔。
工具能省下什麼
這些資料都能用系統命令讀取,診斷並不依賴第三方應用程式。Mole 的「狀態」頁只是把 CPU、記憶體壓力、磁碟、溫度和高占用行程集中到一個頁面。點選行程還能查看它由什麼啟動、是否防止休眠,以及正在讀寫什麼。
避免會同時修改無關狀態的「一鍵加速」。強行清空有用的檔案快取不會帶來持久提升。重新啟動可以結束卡住的行程,也是部分更新的必要步驟,但它可能暫時掩蓋會再次出現的問題。
可重複的診斷步驟
重現卡頓後,同時觀察 CPU、記憶體壓力、磁碟容量與讀寫、散熱和網路。每次只改變一個變數,再用相同負載複測。找到飽和資源,才知道該關閉行程、釋放空間、改善散熱,還是等待網路服務恢復。