CPU 分析
本指南提供詳細的技術，可讓您用來調查中央處理單位， (影響評估計量的 CPU) 相關問題。
評定特定分析指南中的個別計量或問題區段會識別常見的調查問題。 本指南提供可用來調查這些問題的技術與工具。
本指南中的技術使用 Windows Performance Toolkit (WPT) 中的 Windows 效能分析器 (WPA) 。 WPT 是 Windows 評定與部署套件 (Windows ADK) 的一部分，可以從 Windows 測試人員計畫下載。 如需詳細資訊，請參閱 Windows Performance Toolkit 技術參考。
本指南分為下列三個區段：
本節說明如何在 Windows 10 中管理 CPU 資源。 |
|
本節說明如何在 Windows ADK 工具組中檢視和解譯 CPU 資訊。 |
|
本節包含一組技術，可用來調查和解決與 CPU 效能相關的常見問題。 |
背景
本節包含有關 CPU 效能的簡單描述和基本討論。 如需本主題的更全面研究，建議您參閱 Windows Internals， Fifth Edition 書籍。
新式電腦可以包含安裝在個別通訊端中的多個 CPU。 每個 CPU 可以裝載多個實體處理器核心，每個核心都能夠同時處理一或兩個不同的指令資料流程。 這些個別指令資料流程處理器是由 Windows 作業系統作為邏輯處理器所管理。
在本指南中，處理器和 CPU 都是指邏輯處理器，也就是作業系統可用來執行程式指示的硬體裝置。
Windows 10主動以兩種主要方式管理處理器硬體：電源管理、平衡耗電量和效能，以及使用方式，以平衡程式和驅動程式的處理需求。
處理器電源管理
處理器不一定會處於作業狀態。 當沒有任何指示可供執行時，Windows 會將處理器置於目標閒置狀態 (或 C 狀態) ，如 Windows Power Manager 所決定。 根據 CPU 使用量模式，處理器的目標 C 狀態將會隨著時間調整。
閒置狀態是 C0 (作用中狀態的編號狀態;不會閒置) 透過漸進式較低的電源狀態。 這些狀態包括 C1 (已停止，但時鐘仍會) 啟用、C2 (停止，而且時鐘已停用) 等等。 閒置狀態的實作是處理器特定的。 不過，所有處理器中較高的狀態號碼會反映較低的耗電量，但也會等待較長的等候時間，處理器才能返回指令處理。 花費在閒置狀態的時間會大幅影響能源使用和電池使用時間。
某些處理器可以在 P-) (效能中運作，即使它們正主動處理指示，也會 (T-) 狀態進行節流。 P 狀態會定義處理器支援的時鐘頻率和電壓等級。 T 狀態不會直接變更時鐘頻率，但可以略過某些時鐘刻度分數上的處理活動，以降低有效的時脈速度。 一起，目前的 P 和 T 狀態會決定處理器的有效作業頻率。 較低的頻率對應至較低的效能和較低的耗電量。
Windows Power Manager 會根據 CPU 使用模式和系統電源原則，判斷每個處理器的適當 P 和 T 狀態。 花費在高效能狀態與低效能狀態的時間，會大幅影響能源使用和電池使用時間。
處理器使用方式管理
Windows 使用三個主要抽象概念來管理處理器使用量。
處理序
執行緒
) 和中斷 ISR (ISR) 的延後程序呼叫 (DPC
處理序和執行緒
Windows 中的所有使用者模式程式都會在 進程的內容中執行。 套裝程式含下列屬性和元件：
虛擬位址空間
Priority 類別
載入的程式模組
環境和組態資訊
至少一個執行緒
雖然進程包含程式模組、內容和環境，但它們不會直接排程在處理器上執行。 相反地，進程所擁有的執行緒會排程在處理器上執行。
執行緒會維護執行內容資訊。 幾乎所有計算都是線上程中管理。 執行緒活動基本上會影響測量和系統效能。
由於系統中的處理器數目有限，因此無法同時執行所有線程。 Windows 會實作處理器時間共用，讓執行緒在處理器切換至另一個執行緒之前執行一段時間。 線上程之間切換的動作稱為 內容切換 ，並由稱為 發送器的Windows 元件執行。 發送器會根據 優先順序、 理想的處理器和親和性、 量子和 狀態，進行執行緒排程決策。
優先順序
優先順序是發送器如何選取要執行的執行緒的重要因素。 執行緒優先順序是從 0 到 31 的整數。 如果執行緒是可執行檔，且優先順序高於目前執行中的執行緒，則會立即先占較低優先順序的執行緒，且優先順序較高的執行緒會切換為內容切換。
當執行緒正在執行或準備好執行時，除非有足夠的處理器可以同時執行這兩個執行緒，或除非較高優先順序的執行緒僅限於在可用處理器子集上執行，否則無法執行較低優先順序的執行緒。 執行緒具有基底優先順序，可在特定時間暫時提升為較高的優先順序：例如，當進程擁有前景視窗或 I/O 完成時。
理想的處理器和親和性
執行緒 的理想處理器和親和性 會決定指定執行緒排程要執行的處理器。 每個執行緒都有一個理想的處理器，由程式設定或由 Windows 自動設定。 Windows 會使用迴圈配置資源方法，讓每個處理常式中大約相等的執行緒數目指派給每個處理器。 可能的話，Windows 會排程執行緒在其理想的處理器上執行;不過，執行緒偶爾可以在其他處理器上執行。
執行緒的處理器親和性會限制執行緒執行所在的處理器。 這是比執行緒的理想處理器屬性更強大的限制。 程式會使用 SetThreadAffinityMask來設定親和性。 同質性可防止執行緒在特定處理器上執行。
Quantum
內容切換是昂貴的作業。 Windows 通常允許每個執行緒在切換至另一個執行緒之前，先執行一段時間稱為 量子 。 量子持續時間的設計目的是要保留明顯的系統回應性。 它會將內容切換的額外負荷降到最低，以最大化輸送量。 用戶端和伺服器之間的量子持續時間可能會有所不同。 量子持續時間通常會在伺服器上較長，以犧牲明顯的回應性來最大化輸送量。 在用戶端電腦上，Windows 會整體指派較短的量子，但會將較長的量子提供給與目前前景視窗相關聯的執行緒。
狀態
每個執行緒在任何指定時間都處於特定執行狀態。 Windows 使用三種與效能相關的狀態;以下是： 執行中、 就緒和 等候。
目前正在執行的執行緒處於 執行中狀態 。 可執行但目前未執行的執行緒處於 就緒 狀態。 因為執行緒正在等候特定事件處於 Waiting 狀態， 所以無法執行。
圖 1 執行緒狀態轉換中顯示狀態對狀態轉換：
圖 1 執行緒狀態轉換
圖 1 執行緒狀態轉換的說明如下：
執行中狀態的執行緒會呼叫 WaitForSingleObject 或 Sleep (> 0) 等等候函式，以起始對 Wait 狀態的轉換。
執行中的執行緒或核心作業會讀取處於等候狀態 (的執行緒，例如 SetEvent 或計時器到期) 。 如果處理器閒置，或整備執行緒的優先順序高於目前執行中的執行緒，則整備執行緒可以直接切換至 [執行中] 狀態。 否則，它會進入就緒狀態。
當執行中的執行緒等候、產生 (睡眠 (0) ) 或到達其量子的結尾時，發送器會排定處於就緒狀態的執行緒進行處理。
執行中狀態的執行緒會切換出來，並在發送器優先進入較高優先順序執行緒時進入就緒狀態，產生 (Sleep (0) ) ，或其量子結束時。
存在於等候狀態的執行緒不一定表示效能問題。 大部分執行緒在等候狀態中花費大量時間，這可讓處理器進入閒置狀態並節省能源。 只有在使用者等候執行緒完成作業時，執行緒狀態才會成為效能的重要因素。
DPC 和 ISR
除了處理執行緒之外，處理器還會回應來自硬體裝置的通知，例如網路卡或計時器。 當硬體裝置需要處理器注意時，它會產生 中斷。 Windows 會暫停目前正在執行的執行緒，並執行與中斷相關聯的 ISR，以回應硬體中斷。
在執行 ISR 期間，可以防止處理器處理任何其他活動，包括其他中斷。 基於這個理由，ISR 必須快速完成，否則系統效能可能會降低。 為了減少執行時間，ISR 通常會排程 DPC 來執行必須完成的工作，以回應中斷。 針對每個邏輯處理器，Windows 會維護排程的 DPC 佇列。 DPC 會優先于任何優先順序層級的執行緒。 處理器回到處理執行緒之前，它會在其佇列中執行所有 DPC。
在處理器執行 DPC 和 ISR 期間，該處理器上無法執行任何執行緒。 此屬性可能會導致執行緒必須在特定輸送量或精確計時執行工作的執行緒發生問題，例如播放音訊或視訊的執行緒。 如果用來執行 DPC 和 ISR 的處理器時間會防止這些執行緒收到足夠的處理時間，執行緒可能無法達到所需的輸送量或及時完成其工作專案。
Windows ADK 工具
Windows ADK 會將硬體資訊和評量寫入 評定結果檔案。 WPA 提供各種圖表中 CPU 使用量的詳細資訊。 本節說明如何使用 Windows ADK 和 WPA 來收集、檢視和分析 CPU 效能資料。
Windows ADK 評定結果檔案
由於 Windows 僅支援對稱式多處理系統，因此本節中的所有資訊都會套用至所有已安裝的 CPU 和核心。
詳細的 CPU 硬體資訊位於 EcoSysInfo 節點下 <Processor><Instance id=”0”> 評量結果檔的 區段中。
例如：
<Processor>
<Instance id="0">
<ProcessorName>The name of the first CPU</ProcessorName>
<TSCFrequency>The maximum frequency of the first CPU</TSCFrequency>
<NumProcs>The total number of processors</NumProcs>
<NumCores>The total number of cores</NumCores>
<NumCPUs>The total number of logical processors</NumCPUs>
...and so on...
WPA 圖形
將追蹤載入 WPA 之後，您可以在 WPA UI 的 Trace/System Configuration/General 和 Trace/System Configuration/PnP 區段下找到處理器硬體資訊。
注意 本指南中的所有程式都會發生在 WPA 中。
CPU 閒置狀態圖表
如果在追蹤中收集閒置狀態資訊， Power/CPU 閒置狀態 圖表會顯示在 WPA UI 中。 此圖表一律包含每個處理器 的目標 閒置狀態資料。 如果處理器支援此狀態，圖表也會包含每個處理器 實際 閒置狀態的相關資訊。
下表中的每個資料列描述處理器的目標或實際狀態的閒置狀態變更。 下列資料行適用于圖形中的每個資料列：
| 資料行 | 詳細資料 |
|---|---|
CPU |
受狀態變更影響的處理器。 |
輸入時間 |
處理器進入閒置狀態的時間。 |
結束時間 |
處理器結束閒置狀態的時間。 |
max：Duration (ms) |
花費在閒置狀態的時間 (預設匯總：最大值) 。 |
Min：Duration (ms) |
花費在閒置狀態的時間 (預設匯總：最小值) 。 |
下一個狀態 |
處理器在目前狀態之後轉換的狀態。 |
上一個狀態 |
處理器在目前狀態之前轉換的狀態。 |
狀態 |
目前的閒置狀態。 |
狀態 (數值) |
目前的閒置狀態為數字 (例如，C0) 為 0。 |
Sum：Duration (ms) |
花費在閒置狀態的時間 (預設匯總：sum) 。 |
資料表 |
未使用 |
類型 |
針對 處理器) 的 Power Manager 選取目標狀態的目標 (，或 處理器) 的實際閒置狀態的實際 (。 |
預設 WPA 設定檔提供此圖表的兩個預設值： 依類型、CPU 和 依類型顯示的狀態圖表、CPU。
依類型、CPU 的狀態
每個 CPU 的 [目標] 和 [實際] 狀態會與 [依類型]、[CPU] 圖表中Y軸上的狀態號碼一起繪製。 圖 2 CPU 閒置狀態依類型顯示 CPU 的實際狀態，因為 CPU 在作用中和目標閒置狀態之間變動。
圖 2 依類型、CPU 的 CPU 閒置狀態狀態
依類型、CPU 的狀態圖表
在此圖表中，每個 CPU 的目標和實際狀態會以時間軸格式呈現。 每個狀態在時間軸中都有個別的資料列。 圖 3 依類型顯示 CPU 閒置狀態狀態圖表，CPU 在時間軸檢視中顯示與圖 2 CPU 閒置狀態狀態依類型、CPU 相同的資料。
圖 3 依類型、CPU 的 CPU 閒置狀態狀態圖表
CPU 頻率圖表
如果在支援多個 P 或 T 狀態的系統上收集 CPU 頻率資料，則會在 WPA UI 中使用 CPU 頻率 圖表。 下表中的每個資料列都代表處理器的特定頻率層級的時間。 Frequency (MHz) 資料行包含與處理器支援的 P 狀態和 T 狀態對應的有限頻率數目。 下列資料行適用于圖形中的每個資料列：
| 資料行 | 詳細資料 |
|---|---|
% 工期 |
持續時間會以目前可見時段的總 CPU 時間百分比表示。 |
Count |
個別資料列) 的頻率變更 (一律為 1。 |
CPU |
受到頻率變更影響的 CPU。 |
輸入時間 |
CPU 進入 P 狀態的時間。 |
結束時間 |
CPU 結束 P 狀態的時間。 |
頻率 (MHz) |
在處於 P 狀態的期間 CPU 頻率。 |
max：Duration (ms) |
花費在 P 狀態的時間 (預設匯總：最大值) 。 |
Min：Duration (ms) |
花費在 P 狀態的時間 (預設匯總：最小值) 。 |
Sum：Duration (ms) |
花費在 P 狀態的時間 (預設匯總：sum) 。 |
資料表 |
未使用 |
類型 |
P 狀態的其他資訊。 |
預設設定檔會定義此圖形的 CPU 預設頻率 。 圖 4 CPU 依 CPU 的 CPU 頻率會顯示在三個 P 狀態之間轉換的 CPU：
圖 4 依 CPU 的 CPU 頻率
CPU 使用量 (取樣) 圖形
CPU 使用量 (取樣) 圖表中顯示的資料代表以定期取樣間隔採取的 CPU 活動樣本。 在大部分的追蹤中，這 (1 毫秒) 。 資料表中的每個資料列都代表單一範例。
樣本的權數代表該樣本相對於其他樣本的重要性。 權數等於目前樣本的時間戳記減去上一個樣本的時間戳記。 權數不一定等於取樣間隔，因為系統狀態和活動中的波動。
圖 5 CPU 取樣代表如何收集資料：
圖 5 CPU 取樣
此取樣方法不會記錄樣本之間發生的任何 CPU 活動。 因此， CPU 取樣 圖表中未妥善表示非常短持續時間的活動，例如 DPC 和 ISR。
下列資料行適用于圖表中的每個資料列：
| 資料行 | 詳細資料 |
|---|---|
百分比權數 |
權數會以目前可見時間範圍所花費的總 CPU 時間百分比表示。 |
位址 |
位於堆疊頂端之函式的記憶體位址。 |
所有計數 |
資料列所代表的樣本數目。 此數目包含處理器閒置時所採取的範例。 對於個別資料列，此資料行一律為 1。 |
Count |
資料列所代表的樣本數目，不包括處理器閒置時所採取的樣本。 針對個別資料列，此資料行一律為 1 (或 0，若 CPU 處於低電源狀態) 。 |
CPU |
採用此範例之 CPU 的 0 型索引。 |
顯示名稱 |
使用中進程的顯示名稱。 |
DPC/ISR |
樣本測量的一般 CPU 使用量、DPC/ISR 或低電源狀態。 |
函式 |
堆疊頂端的 函式。 |
模組 |
包含堆疊頂端函式的模組。 |
優先順序 |
執行中線程的優先順序。 |
處理序 |
擁有執行中程式碼之進程的映射名稱。 |
處理序名稱 |
完整名稱 (包括擁有執行程式碼的進程識別碼) 。 |
Stack |
執行中線程的堆疊。 |
執行緒識別碼 |
執行中線程的識別碼。 |
執行緒啟動函式 |
執行中線程啟動的函式。 |
執行緒啟動模組 |
包含執行緒啟動函式的模組。 |
TimeStamp |
取得樣本的時間。 |
Weight |
以) 毫秒為單位的時間 (，由樣本 (表示，也就是自上一個樣本) 以來的時間。 |
預設設定檔提供此圖表的下列預設值：
CPU 使用率
依優先順序的使用率
依進程使用
依進程和執行緒的使用率
CPU 使用率
CPU 使用量依 CPU圖表顯示如何在處理器之間散發工作。 圖 6 CPU 的 CPU 使用量使用量顯示兩個 CPU 的此散發：
圖 6 CPU 使用量依 CPU 使用量
依優先順序的使用率
依執行緒優先順序分組的CPU 使用量會顯示高優先順序執行緒如何影響低優先順序執行緒。 圖 7 CPU 使用量 (依優先順序取樣) 使用率顯示此圖表：
圖 7 依優先順序取樣的 CPU 使用量 (取樣) 使用率
依進程使用
依進程分組的CPU 使用量會顯示進程的相對使用量。 圖 8 CPU 使用量 (依進程取樣) 使用率顯示此預設。 在此範例圖表中，一個進程會顯示耗用比其他進程更多的 CPU 時間。
圖 8 CPU 使用量 (依進程取樣) 使用率
依進程和執行緒的使用率
依進程分組的CPU 使用量，然後依執行緒分組會顯示進程和每個進程中線程的相對使用量。 圖 9 CPU 使用量 (依進程和執行緒取樣) 使用率顯示此預設。 此圖表中會選取單一進程的執行緒。
圖 9 CPU 使用量 (依進程和執行緒取樣) 使用率
CPU 使用量 (精確) 圖形
CPU 使用量 (精確) 圖表會記錄與內容切換事件相關聯的資訊。 每個資料列都代表一組與單一內容切換相關聯的資料;也就是說，當執行緒開始執行時。 系統會針對下列事件順序收集資料：
新的執行緒已切換出。
新的執行緒已準備好由就緒執行緒執行。
新的執行緒會切換至 中，藉此切換出舊的執行緒。
新的執行緒會再次切換出來。
在圖 10 CPU 使用量精確圖表中，時間從左至右流動。 圖表標籤會對應至 CPU 使用量 (精確) 圖表中的資料行名稱。 [時間戳記] 資料行的標籤會顯示在圖表頂端，而[間隔持續時間] 資料行的標籤會顯示在圖表底部。
圖 10 CPU 使用量精確圖表
圖 10 CPU 使用量精確圖表中的時間軸中斷會將時間軸分割成可在不同 CPU 上同時發生的區域。 只要未修改編號事件的順序，這些時間軸就可以重迭。 例如，「就緒執行緒」可以在 Processor-2 上執行，同時切換出新的執行緒，然後在 Processor-1) 上返回。
時間軸上會記錄下列四個目標的資訊：
新執行緒，這是已切換的執行緒。 這是圖表中這個資料列的主要焦點。
NewPrev 執行緒，這是指先前已切換新執行緒的時間。
準備執行緒，這是準備處理新執行緒的執行緒。
舊執行緒，這是切換新執行緒時已切換出的執行緒。
下表中的資料與每個目標執行緒有關：
| 資料行 | 詳細資料 |
|---|---|
% CPU 使用量 |
切換後新執行緒的 CPU 使用量。 此值會以目前可見時段的總 CPU 時間百分比表示。 |
Count |
由資料清單示的內容切換數目。 這一律為個別資料列的 1。 |
Count：Waits |
資料列所代表的等候數目。 除了執行緒切換為閒置狀態之外，個別資料列一律為 1;在此情況下，它會設定為 0。 |
CPU |
發生內容切換的 CPU。 |
CPU 使用量 (毫秒) |
內容切換之後新執行緒的 CPU 使用量。 這等於 NewInSwitchTime，但以毫秒為單位顯示。 |
IdealCpu |
排程器為新執行緒選取的理想 CPU。 |
LastSwitchOutTime (s) |
先前已切換出新執行緒的時間。 |
NewInPri |
已切換之新執行緒的優先順序。 |
NewInSwitchTime (s) |
NextSwitchOutTime (s) 減去 SwitchInTime (s) |
NewOutPri |
新執行緒切換時，其優先順序。 |
NewPrevOutPri |
先前切換出新執行緒時的優先順序。 |
NewPrevState |
在先前切換出新執行緒之後的狀態。 |
NewPrevWaitMode |
先前切換出新執行緒的等候模式。 |
NewPrevWaitReason |
已切換出新執行緒的原因。 |
NewPriDecr |
影響執行緒的優先權提升。 |
NewProcess |
新執行緒的進程。 |
NewProcess 名稱 |
新執行緒的進程名稱，包括 PID。 |
NewQnt |
未使用的。 |
NewState |
新執行緒在切換後的狀態。 |
NewThreadId |
新執行緒的執行緒識別碼。 |
NewThreadStack |
當新執行緒切換時，新執行緒的堆疊。 |
NewThreadStartFunction |
新執行緒的 start 函式。 |
NewThreadStartModule |
新執行緒的啟動模組。 |
NewWaitMode |
新執行緒的等候模式。 |
NewWaitReason |
已切換出新執行緒的原因。 |
NextSwitchOutTime (s) |
下一次切換出新執行緒的時間。 |
OldInSwitchTime (s) |
舊執行緒在切換出之前切換的時間。 |
OldOutPri |
切換出舊執行緒時的優先順序。 |
OldProcess |
擁有舊執行緒的進程。 |
OldProcess 名稱 |
擁有舊執行緒的進程名稱，包括 PID。 |
OldQnt |
未使用的。 |
OldState |
切換出舊執行緒之後的狀態。 |
OldThreadId |
舊執行緒的執行緒識別碼。 |
OldThreadStartFunction |
舊執行緒的 start 函式。 |
OldThreadStartModule |
舊執行緒的啟動模組。 |
OldWaitMode |
舊執行緒的等候模式。 |
OldWaitReason |
已切換出舊執行緒的原因。 |
PrevCState |
處理器先前的 CState。 如果這不是 0 (Active) ，處理器在新的執行緒切換內容之前處於閒置狀態。 |
就緒 () |
SwitchInTime (s) minusReadyTime (s) |
Readying ThreadId |
就緒執行緒的執行緒識別碼。 |
Readying ThreadStartFunction |
就緒執行緒的 start 函式。 |
Readying ThreadStartModule |
就緒執行緒的開始模組。 |
ReadyingProcess |
擁有就緒執行緒的進程。 |
ReadyingProcess 名稱 |
擁有就緒執行緒的進程名稱，包括 PID。 |
ReadyThreadStack |
就緒執行緒的堆疊。 |
ReadyTime (s) |
新執行緒整備的時間。 |
SwitchInTime (s) |
新執行緒切換的時間。 |
TimeSinceLast (s) |
SwitchInTime (s) 減去 LastSwitchOutTime (s) |
等候 () |
ReadyTime (s) 減去 LastSwitchOutTime (s) |
預設設定檔會針對此圖表使用下列預設值：
依 CPU 的時程表
依進程、執行緒的時程表
依內容切換開始優先順序的使用方式
依 CPU 的使用率
依進程、執行緒的使用率
依 CPU 的時程表
每個 CPU 時間軸上的CPU 使用量會顯示如何在處理器之間散發工作。 圖 11 CPU 使用量 (依 CPU 的精確) 時間軸顯示八個處理器系統上的時間軸：
圖 11 CPU 使用量 (依 CPU 的精確) 時間軸
依進程、執行緒的時程表
每個進程、每個執行緒時間軸上的CPU 使用量會顯示哪些進程在特定時間執行執行緒。 圖 12 使用方式 (依進程精確) 時間軸，Thread 會顯示此時間軸，橫跨數個進程：
圖 12 依進程、執行緒 (精確) 時間軸的使用方式
依內容切換開始優先順序的使用方式
此圖表會識別每個優先順序層級的高優先順序執行緒活動高載。 圖 13 CPU 使用量 (精確) 內容切換開始優先順序的使用量顯示優先順序的分佈：
圖 13 CPU 使用量 (內容切換開始時優先順序的精確) 使用量
依 CPU 的使用率
在此圖表中，CPU 使用量會分組並依 CPU 繪製圖形，以顯示工作在處理器之間分佈的方式。 圖 14 CPU 使用量 (CPU 的精確) 使用率，顯示具有八個處理器的系統此圖表。
圖 14 CPU 使用量 (CPU 的精確) 使用率
依進程、執行緒的使用率
在此圖表中，CPU 使用量會先依進程和執行緒分組。 它會顯示進程和每個進程中線程的相對使用量圖 15 CPU 使用量 (依進程精確) 使用率，執行緒會顯示此分散到多個進程：
圖 15 CPU 使用量 (依進程、執行緒精確) 使用率
DPC/ISR 圖形
DPC/ISR 圖表是 WPA 中 DPC/ISR 資訊的主要來源。 圖形中的每個資料列都代表片段，這是 DPC 或 ISR 執行未中斷的一段時間。 資料會在片段的開頭和結尾收集。 當 DPC/ISR 完成時，會收集其他資料。 圖 16 DPC/ISR 圖表顯示運作方式：
圖 16 DPC/ISR 圖表
圖 16 DPC/ISR 圖表描述在下列活動期間收集的資料：
DPC/ISR-A 會開始執行。
比 DPC/ISR-A 高插斷層級的裝置中斷會導致 ISR-B 中斷 DPC/ISR A，進而結束 DPC/ISR-A的第一個片段。
ISR-B 會完成並結束 ISR-B的片段。 DPC/ISR-A 會在第二個片段中繼續執行。
DPC/ISR-A 完成，因而結束 DPC/ISR-A的第二個片段。
每個片段的資料列都會顯示在資料表中。 DPC/ISR-A的片段會與非片段資料行共用相同的資訊。
DPC/ISR 圖表的資料行描述片段層級資訊，或 DPC/ISR 層級資料行。 片段層級資料行中的每個片段都不同，以及 DPC/ISR 資料行中的相同資料。
| 資料行 | 詳細資料 |
|---|---|
% 持續時間 (分散) |
持續時間 (分散) ，以目前可見時段的總 CPU 時間百分比表示。 |
% 獨佔持續時間 |
以目前可見時間週期內總 CPU 時間百分比表示的獨佔持續時間。 |
% 內含持續時間 |
內含持續時間，以目前可見時段的總 CPU 時間百分比表示。 |
位址 |
DPC 或 ISR 函式的記憶體位址。 |
) 計數 (DPC/ISR |
此資料列所代表的 DPC/ISR 計數。 對於代表 DPC/ISR 最終片段的資料列而言，這一律為 1;否則，此計數為 0。 |
計數 (片段) |
資料列所代表的片段數目。 這一律為個別資料列的 1。 |
CPU |
執行 DPC 或 ISR 之邏輯處理器的索引。 |
DPC 類型 |
針對 DPC，DPC 的類型為一般或計時器。 ISR 的這個值是空白的。 |
DPC/ISR 輸入時間 (s) |
DPC/ISR 啟動時追蹤中的時間。 |
DPC/ISR 結束時間 (s) |
從追蹤開始到 DPC/ISR 完成的時間。 |
持續時間 (分散) (毫秒) |
片段結束時間 (秒) 減去片段輸入時間 (毫秒) 。 |
獨佔持續時間 (ms) |
此 DPC/ISR 之所有片段的分散持續時間總和。 |
片段 |
如果此資料列的 DPC/ISR 有多個片段，則此值為 True;否則為 False。 |
片段 |
如果這不是這個 DPC/ISR 的唯一片段，則此值為 True;否則為 False。 |
片段輸入時間 (s) |
片段開始執行的時間。 |
片段結束時間 () |
片段停止執行的時間。 |
函式 |
執行的 DPC 或 ISR 函式。 |
包含持續時間 (ms) |
DPC/ISR 結束時間 (s) 減去 DPC/ISR 輸入時間 (毫秒) 。 |
MessageIndex |
訊息訊號中斷的中斷索引。 |
模組 |
包含 DPC 或 ISR 函式的模組。 |
傳回值 |
DPC/ISR 的傳回值 |
類型 |
事件的類型;這是 DPC 或中斷 (ISR) 。 |
向量 |
裝置上中斷向量的值。 |
預設設定檔會針對此圖表使用下列預設值：
[DPC，ISR，DPC/ISR]依 CPU 的持續時間
[DPC，ISR，DPC/ISR]依模組、函式的持續時間
[DPC，ISR，DPC/ISR]依模組、函式的時程表
[DPC，ISR，DPC/ISR]依 CPU 的持續時間
DPC/ISR 事件是由其執行所在的 CPU 匯總，並依持續時間排序。 此圖表顯示跨 CPU 配置 DPC 活動。 圖 17 DPC/ISR 依 CPU 的持續時間會顯示具有八個處理器的系統此圖表。
圖 17 依 CPU 的 DPC/ISR 持續時間
[DPC，ISR，DPC/ISR]依模組、函式的持續時間
DPC/ISR 事件會依 DPC/ISR 常式的模組和函式在此圖表中匯總，並依持續時間排序。 這會顯示哪一個 DPC/ISR 常式耗用最多時間圖 18 DPC/ISR 持續時間的模組，函式會顯示兩個模組中會產生 DPC/ISR 活動的期間：
圖 18 依模組、函式的 DPC/ISR 持續時間
[DPC，ISR，DPC/ISR]依模組、函式的時程表
DPC/ISR 事件是由 DPC/ISR 常式的模組和函式在此圖表中匯總。 它們會以時間軸的形式繪製。 此圖表提供 DPC/ISR 執行期間的詳細檢視。 此圖表也可以顯示單一 DPC/ISR 如何分散。 圖 19 依模組排列的 DPC/ISR 時程表，函式會顯示三個模組中的啟用時間表：
圖 19 依模組、函式的 DPC/ISR 時程表
堆疊樹狀結構
堆疊樹狀結構會顯示在 CPU 使用量 (取樣) 、 CPU 使用量 ( WPA 中的精確) 和 DPC/ISR 資料表，以及評量報告中回報的問題。 堆疊樹狀結構會讓呼叫堆疊在一段時間內與多個事件相關聯。 樹狀結構中的每個節點都代表由事件子集共用的堆疊區段。 樹狀結構是從個別堆疊建構，如圖 20 從三個事件堆疊顯示：
圖 20 三個事件的堆疊
圖 21 已識別的常見區段顯示如何識別此圖表的常見序列：
圖 21 識別的常見區段
圖 22 從堆疊建置的樹狀結構顯示如何結合通用區段，以形成樹狀結構的節點：
圖 22 從堆疊建置的樹狀結構
WPA UI 中的 [堆疊 ] 資料行包含每個非分葉節點的展開器。 在評量回報的問題中，樹狀結構會與匯總權數一起顯示。 如果某些分支的權數不符合指定的臨界值，則可以從圖形中移除。 下列範例堆疊顯示上述事件如何顯示為評量回報問題的一部分。
5ms ModuleA!Function1
5ms ModuleA!Function2
5ms ModuleA!Function3
|
4ms |-ModuleA!Function4
4ms | ModuleB!Function1
| |
1ms | |-ModuleB-Function2
1ms | | ModuleB-Function3
| |
3ms | |-ModuleB!Function3
3ms | ModuleB!Function4
|
1ms |-ModuleA!Function5
1ms ModuleC!Function1
1ms ModuleC!Function2
<itself>堆疊中的節點代表函式本身位於堆疊頂端的時間。 節點 <itself> 不包含父函式所呼叫函式所花費的時間。 該持續時間稱為函式中花費 的獨佔 時間。
例如， Function1 會呼叫 Function2。 Function2 花費了 2 毫秒的 CPU 密集迴圈，並呼叫另一個針對 4 毫秒執行的函式。 這可由下列堆疊表示：
6ms ModuleA!Function1
|
2ms |-<itself>
4ms |-ModuleA!Function2
4ms ModuleB!Function3
4ms ModuleB-Function4
技術
本節說明效能分析的標準方法。 它提供可用來調查常見 CPU 相關效能問題的技巧。
效能分析是四個步驟的程式：
定義案例和問題。
識別涉及的元件和相關時間範圍。
建立應該發生的模型。
使用模型來識別問題並調查根本原因。
定義案例和問題
效能分析的第一個步驟是清楚定義案例和問題。 許多效能問題會影響評估計量所測量的案例。 例如：
案例 1：實體資源未完全利用。 例如，伺服器無法完全利用網路連線，因為它無法快速加密封包。
案例 2：實體資源已使用超過其預期。 例如，系統會在閒置期間使用大量 CPU 資源，以使用電池電力。
案例 3：活動未以必要的速率完成。 例如，視訊播放期間會卸載畫面，因為畫面的速度不夠快。
案例 4：活動已延遲。 例如，使用者啟動 Internet Explorer，但開啟索引標籤所花費的時間超過預期。
本指南涵蓋與 CPU 資源相關的案例 3 和 4。 案例 1 和 2 不在範圍中，且未涵蓋。 若要分析這些問題，您可以從模棱兩可的觀察開始，例如「太慢」，並詢問其他問題來識別案例和確切的問題。
識別元件和時間週期
在識別案例和問題之後，您可以識別涉及的元件和感興趣的時間週期。 這些元件包括硬體資源、進程和執行緒。
在分析指南中識別相關聯的活動，您通常可以找到感興趣的時間範圍。 活動是開始事件與停止事件之間的間隔，您可以在 WPA 中選取和放大。 如果未定義活動，您可以尋找與案例相關聯的特定泛型事件，或尋找可能標示案例開頭和結尾的資源使用率變更，以尋找時間範圍。 例如，如果 CPU 閒置兩秒，然後完全利用四秒，然後再次閒置兩秒，則完整使用率的四秒可能是擷取視訊播放追蹤感興趣的區域。
建立模型
若要瞭解問題的根本原因，您必須有應該發生的模型。 此模型會從計量的問題或任何相關聯的目標開始;例如，「此作業應該在 5 秒內完成」。
更完整的模型包含元件執行方式的相關資訊。 例如，元件之間預期的通訊為何？ 什麼是一般資源使用率？ 作業通常需要多久的時間？
模型的資訊通常可在評定分析指南中找到。 如果無法使用該資源，您可以從未顯示效能問題的類似硬體和軟體產生追蹤，以建立模型。
使用模型來識別問題，然後調查根本原因
擁有模型之後，您可以比較追蹤與模型來識別問題。 例如，名為Suspend Devices的特定活動模型可能會建議整個活動應該在三秒內完成，而名為Suspend < Device Name >之子活動的每個實例應該不超過 100 毫秒。 如果子活動的兩個實例「暫停 < 裝置名稱 >」每一個需要 800 毫秒，您應該調查這些實例。
您可以分析模型的每個偏差，以找出根本原因。 您應該檢查涉及執行緒的狀態，並尋找常見的根本原因。 以下是一些主要 CPU 相關根本原因，說明未以必要速率完成或延遲的活動：
直接 CPU 使用量：適當的執行緒收到完整的 CPU 資源，但必要的程式執行速度不夠快。 這可能會因為程式故障或硬體變慢所造成。
執行緒干擾：執行緒沒有足夠執行時間，因為其他執行緒正在執行。 在此情況下，執行緒會被視為已耗盡或先占。
DPC/ISR 干擾：執行緒沒有足夠的執行時間，因為 CPU 正在忙碌處理 DPC 或 ISR。
在許多情況下，其中一個根本原因不會明顯影響執行緒，而執行緒會花費大部分的時間處於等候狀態。 在此情況下，您必須識別並調查執行緒正在等候的事件。 這種遞迴調查類型稱為 等候分析，從識別關鍵路徑開始。
進階技術：等候分析和關鍵路徑
活動是作業網路，一些循序和一些平行，從開始事件流向結束事件。 追蹤中的任何開始/結束事件組都可以視為活動。 透過此作業網路的最大路徑稱為關鍵路徑。 減少關鍵路徑上任何作業的持續時間，會直接減少整體活動的持續時間，不過也可以變更關鍵路徑。
圖 23 活動作業顯示三個執行緒的活動。 Thread-1 會傳送活動開始事件，然後等候 Thread-2 和 Thread-3 完成其工作。 Thread-2 會先完成其工作，後面接著 Thread-3。 當這兩個執行緒都已完成其工作時，Thread-1 會整備並完成活動事件。
圖 23 活動作業
在此案例中，關鍵路徑包含 Thread-3 和 Thread-1 的部分。 這些追蹤于圖 24 重大路徑中。 因為 Thread-2 不在關鍵路徑上，所以完成其工作所需的時間不會影響整體啟用時間。
圖 24 重大路徑
關鍵路徑是一個低階常值答案，可回答活動為何花費太多時間的問題。 已知重要路徑的主要區段之後，可以分析這些區段來找出造成整體延遲的問題。
尋找重要路徑的一般方法
尋找關鍵路徑的第一個步驟是檢閱案例模型，以瞭解活動的用途和實作。
瞭解活動有助於識別可能位於重要路徑上的特定作業、進程和執行緒。 例如， 快速啟動繼續總管 Init 活動的延遲可能是 RunOnce 應用程式和 Explorer 初始化程式所造成，這兩者都需要大量的 I/O。
檢閱案例模型之後，請檢查評量是否回報受影響活動的任何問題。 許多時候，重大路徑的近似值會包含在評量報告的延遲問題中。 重大路徑會顯示為一連串的等候和就緒動作。 您可以從頭到尾讀取為事件序列，其中主要延遲區段位於清單中間的重要路徑。 清單中的最後一個專案是準備完成活動的執行緒的動作。
如果您必須手動尋找關鍵路徑，建議您識別完成活動的流程和執行緒，並從活動完成的立即回溯工作。 您可以透過 WPA 中的 活動 圖表，識別啟動活動的進程和執行緒，以及完成活動的進程和執行緒。
當追蹤透過評定結果 XML 檔案載入時， [活動 ] 圖表會顯示。 若要識別與特定活動相關聯的進程和執行緒，請將圖表展開至感興趣的活動，然後將檢視切換至 Graph+Table。 將圖形模式設定為 [資料表]。 [開始進程]、[開始執行緒識別碼]、[結束進程] 和 [結束執行緒識別碼] 資料行會顯示資料表中每個活動。
在您知道開始和結束進程、執行緒和活動實作之後，就可以向後追蹤關鍵路徑。 從分析完成活動的執行緒開始，以判斷該執行緒花費大部分時間的方式：執行、就緒或等候。
重要的運行時程表示直接 CPU 使用量可能會造成重大路徑的持續時間。 在就緒模式中花費的時程表示其他執行緒會藉由防止重要路徑上的執行緒執行，來參與重大路徑的持續時間。 等候點到 I/O、計時器或其他執行緒和進程所花費的時間，位於目前線程正在等候的重要路徑上。
每個整備目前線程的執行緒可能是關鍵路徑的另一個連結，也可以進行分析，直到重要路徑的持續時間考慮為止。
程式：在 WPA 中尋找關鍵路徑
下列程式假設您已在 [活動] 圖表中識別出您想要尋找重要路徑的活動。
您可以藉由將滑鼠停留在 活動 圖表中的活動上方，來識別完成活動的程式。
新增 CPU 使用量 (精確) 圖形。 縮放至受影響的活動，並 套用依進程、執行緒 預設的使用率。
以滑鼠右鍵按一下資料行標頭，並讓 ReadyThreadStack 和 CPU 使用量 (ms) 資料行可見。 移除 [就緒 () [Max] 和 [ 等候 () [Max] 資料行。
展開目標進程，然後依 CPU 使用量 (ms) 、 Ready (us) [Sum]，以及 [Sum] ( (我們) [Sum]來排序它。
在進程中搜尋 NewThreadIds ，其花費在 [執行中]、[就緒] 或 [等候] 狀態所花費的時間上限。
在 [執行中] 或 [就緒] 狀態中花費大量時間的執行緒，可能會代表關鍵路徑上的直接 CPU 使用量。 請注意，其執行緒識別碼.執行緒花費大量時間處於等候狀態，可能是在 I/O、計時器或關鍵路徑的另一個執行緒上等候。
若要探索執行緒正在等候的內容，請展開 NewThreadId 群組以顯示 ReadyThreadStack。
展開 [Root]。
以 KiDispatchInterrupt 開頭的堆疊與另一個執行緒無關。 若要判斷線程在這些堆疊中等候的內容，請展開 KiDispatchInterrupt ，並檢視子堆疊上的函式。 IopfCompleteRequest 指出整備的執行緒正在等候 I/O。 KiTimerExpiration 指出整備執行緒正在等候計時器。
展開未以KiDispatchInterrupt開頭的堆疊，直到您看到ReadyingProcess 和 ReadyingThread為止。 如果進程已經展開，請展開對應至ReadyingThread的NewThreadId。 重複此步驟，直到您找到執行緒正在執行、就緒、等候其他原因，或等候不同的進程為止。 如果執行緒正在等候不同的進程，請使用該程式重複此程式。
範例
此範例會在快速啟動繼續總管 Init 活動中顯示延遲。 [ 問題 ] 窗格中的搜尋會顯示此活動的七個延遲類型問題。 每個問題都可以檢閱為重要路徑的區段。 識別下列主要區段：
進程TestBootStrapper.exe (3024) 的執行緒 3872 會先占 2.1 秒。
執行緒 3872 TestBootStrapper.exe (3024) 使用 1 秒的 CPU 時間。
執行緒 3872 進程TestBootStrapper.exe (3024) 排清登錄區 544 毫秒。
進程執行緒 3872 TestBootStrapper.exe (3024) 睡眠 513 毫秒。
從磁片讀取Explorer.exe執行緒 4052 和 4036，造成 461 毫秒的延遲。
進程執行緒 3872 TestBootStrapper.exe (3024) 會耗盡 187 毫秒。
進程執行緒 3872 TestBootStrapper.exe將 3.5MB 寫入磁片，造成 178 毫秒的延遲。
問題顯示此活動延遲 5.2 秒。 這些延遲會參與整體 6.3 秒持續時間的大型活動比例。 TestBootStrapper.exe應用程式主要負責延遲，主要是因為其先占其他處理工作。
調查重大路徑中的問題
縮放至受影響的區域，並新增 ReadyThreadStack 和 CPU 使用量 (ms) 資料行。
在此情況下，Explorer.exe是完成活動的程式。 展開explorer.exe程式，然後依 CPU 使用量 (ms) 、 Ready (us) [Sum]，以及 [Sum] () [Sum]，分別排序它，如下圖所示：
圖 25 依 CPU 使用量 (毫秒的活動)
圖 26 依就緒 (我們)
圖 27 依等候 (我們)
依 CPU 使用量 (ms) 資料行排序會顯示 299 毫秒的前層子資料列。 依 [就緒 (我們排序]，) [Sum] 資料行會顯示 46 毫秒的最上層子資料列。 依 [等候 (我們排序) [Sum] 資料行會顯示頂端子資料列 5749 毫秒，第二個數據列為 4902 毫秒。 由於這些資料列對延遲有顯著影響，因此您應該進一步調查這些資料列。
展開堆疊以顯示就緒的執行緒，如下圖所示：
圖 28 執行緒的準備進程和就緒執行緒
圖 29 準備進程和另一個執行緒的就緒執行緒
在此範例中，第一個執行緒會花大部分的時間等待RunOnce.exe進程結束。 您應該調查為何RunOnce.exe程式需要太多時間才能完成。 第二個執行緒正在等候第一個執行緒，而且可能是相同等候鏈結中不重要的連結。
針對RunOnce.exe重複此程式中的步驟。 主要參與資料行是 等候 (我們) ，而且有四個可能的參與者。
展開每個參與者，以查看前三個參與者分別等候第四個參與者。 這種情況讓前三個參與者對等候鏈結不重要。 第四個參與者正在等候另一個程式，TestBootStrapper.exe。
本案例顯示在圖 30 準備進程和RunOnce.exe執行緒的準備執行緒：
圖 30 RunOnce.exe中線程的準備進程和準備執行緒
針對TestBootStrapper.exe重複此程式中的步驟。 結果會顯示在下列三個圖表中：
圖 31 依 CPU 使用量 (毫秒) 的執行緒
圖 32 就緒的執行緒 (我們)
圖 33 依等候的執行緒 (我們)
執行緒 3872 花費大約 1 秒執行、2 秒就緒，以及等候 1.3 秒。 由於此執行緒也是執行緒 3872 的準備執行緒，因此執行和就緒時間可能會造成延遲。 評估會報告下列符合延遲時間的問題：
進程TestBootStrapper.exe (3024) 的執行緒 3872 會先占 2.1 秒。
進程執行緒 3872 TestBootStrapper.exe (3024) 會耗盡 187 毫秒。
執行緒 3872 TestBootStrapper.exe (3024) 使用 1 秒的 CPU 時間。
若要尋找其他參與的問題，請檢視執行緒 3872 正在等候的事件。 展開 ReadyThreadStack 以檢視等候 1.3 秒的參與者，如圖 34 參與者等候時間所示：
圖 34 等候時間參與者
KiRetireDpcList 通常與 I/O 相關， 而 KiTimerExpiration 是計時器。 您可以移除 ReadyThreadStack ，然後檢視 NewThreadStack來檢視 I/O 和計時器起始的方式。 此檢視會顯示三個相關的函式，如圖 35 I/Os 和 NewThreadStack 上的計時器所示：
圖 35 NewThreadStack 上的 I/O 和計時器
此檢視會揭露下列詳細資料：
執行緒 3872 進程TestBootStrapper.exe (3024) 排清登錄區 544 毫秒。
進程執行緒 3872 TestBootStrapper.exe (3024) 睡眠 513 毫秒。
進程執行緒 3872 TestBootStrapper.exe將 3.5MB 寫入磁片，因而造成 178 毫秒的延遲。
當您開始調查關鍵路徑時，您已分析Explorer.exe中最重要的等候原因，並忽略該等候原因之後所發生之重要路徑的任何部分。 若要擷取先前忽略的重要路徑區段，您必須查看時程表。 新增 CPU 使用量 (精確) ，並 依進程、執行緒預設套用時程表 。
篩選以只包含識別為重要路徑一部分的進程。 產生的圖表會顯示在圖 36 重大路徑時程表中：
圖 36 重大路徑時程表
圖 36 重大路徑時程表顯示Explorer.exe停止等候RunOnce.exe之後執行更多工作。 縮放至先前分析的等候鏈結之後的時間週期，並執行另一個分析。 在此情況下，分析會顯示大量的執行緒，這些執行緒是內部Explorer.exe，而且不會透過重要路徑清楚追蹤。 在此情況下，進一步的分析不太可能產生可採取動作的深入解析。
直接 CPU 使用量
活動通常會延遲，因為關鍵路徑上的執行緒會使用大量的 CPU 時間。 藉由使用執行緒狀態模型，您可以看到此問題的特性在於在執行中狀態花費特殊時間的重要路徑上的執行緒。 在某些硬體上，這種大量 CPU 使用量可能會造成延遲。
問題識別
許多評量會使用啟發學習法來識別直接 CPU 使用量相關問題。 重大路徑上的大量 CPU 使用量會以下列形式回報為問題：
由進程 P 使用的 CPU 會延遲受影響的活動 A數 秒
其中 P 是執行中的進程， A 是活動， 而 x 是以秒為單位的時間。
如果針對產生延遲的活動回報這些問題，則直接 CPU 使用量可能是原因。
調查直接 CPU 使用量
您可以尋找在 CPU 使用量 (取樣) 圖表中產生 100% CPU 使用量的個別 CPU，以手動識別問題。
縮放至圖形中感興趣的區域，然後選取 [ 依進程和執行緒的使用率 ] 預設值。
根據預設，資料表會顯示頂端具有最高匯總 CPU 使用量的資料列。 這些執行緒也會顯示在 CPU 使用量 (取樣) 圖形頂端。
注意 在具有多個處理器的系統上，使用單一處理器 100% 的執行緒似乎耗用 100/ (個邏輯處理器數目) 。 在這類系統上，只有虛擬閒置執行緒 (PID 0、TID 0) 可以顯示比邏輯處理器) 100/ (數目更高的處理器使用率。 如果耗用最多 CPU 的進程和執行緒會對應到關鍵路徑中的任何執行緒，則直接 CPU 使用量可能是一個因素。
Assessment-Reported直接 CPU 使用量問題的範例
TestUM.exe進程使用的 CPU (4024) 延遲受影響的活動、快速啟動關機程式TestIM.exe 2.1 秒。 此範例顯示在圖 37 執行緒 3208 中：
圖 37 執行緒 3208
調查
發現直接 CPU 使用量在關鍵路徑上造成延遲之後，您必須識別造成延遲的特定模組和函式。
技術：檢閱Assessment-Reported直接 CPU 使用量問題
您可以展開評量報告的直接 CPU 使用量問題，以顯示受直接 CPU 使用量影響的重要路徑。 如果您展開與 CPU 使用量相關聯的節點，則會顯示與 CPU 使用量和相關聯模組相關聯的堆疊。 此檢視會顯示在圖 38 展開的 CPU 使用量區段：
圖 38 展開的 CPU 使用量區段
技術：手動探索直接 CPU 使用量問題的堆疊
如果評量未回報問題，或如果您需要額外的驗證，您可以使用 CPU 使用量 (取樣) 圖表，手動收集 CPU 使用量問題所涉及的模組和函式資訊。 若要這樣做，您必須縮放至感興趣的區域，並檢視依 CPU 使用量排序的堆疊。
手動探索直接 CPU 使用量問題的堆疊
在 [追蹤] 功能表上，按一下 [載入符號]。
縮放時間軸，只顯示受 CPU 問題影響的重要路徑部分。
依進程和執行緒預設套用使用率。
將 [堆疊] 資料行新增至顯示，然後將此資料行拖曳至列左側的 [ 執行緒 (識別碼 ] 右邊) 。
展開進程和執行緒以顯示堆疊樹狀結構。
堆疊中的資料列依 CPU 使用量百分比的遞減順序排序。 這會將最有趣的堆疊放在最上方。 當您展開堆疊時，watch %Weight資料行，以確保您的焦點會保留在具有最高使用量的資料列上。
若要擷取堆疊的複本，請選取所有資料列，按一下滑鼠右鍵，然後按一下 [ 複製選取範圍]。
解決方案
您可以在組態和元件層級套用補救，以解決高 CPU 使用量。
直接 CPU 使用量對具有較低處理器的電腦有較高的影響。 在這些情況下，您可以將更多處理能力新增至電腦。 或者，您可能可以從重大路徑或系統移除問題模組。 如果您可以變更元件，請考慮重新設計以達成下列其中一個結果：
從關鍵路徑中移除需要大量 CPU 的程式碼
使用更具 CPU 效率的演算法
延遲或快取工作
執行緒干擾
不在重要路徑 (且可能與活動) 無關之執行緒的 CPU 使用量，可能會導致重要路徑上的執行緒延遲。 執行緒狀態模型顯示此問題的特性是執行緒在花費異常時間處於就緒狀態的重要路徑上。
問題識別
許多評量都使用啟發學習法來識別干擾相關問題。 這些會以下列兩種形式之一回報：
進程 P 已耗盡。 星狀造成受影響活動 A 的 x 毫秒延遲。
進程 P 會先占。 先占會導致受影響活動 A 的 x 毫秒延遲。
其中 P 是進程， A 是活動， 而 x 是毫秒的時間。
第一個表單會反映與重要路徑上執行緒相同優先順序層級之執行緒的干擾。 第二個表單反映與重要路徑上執行緒較高優先順序層級的執行緒干擾。
如果針對延遲的活動回報這些類型的問題，執行緒干擾可能是原因。 您可以使用 CPU 使用量 (精確) 圖形手動識別問題。
識別執行緒干擾問題
縮放至間隔，並 依 CPU 預設套用使用率。 所有 CPU 的使用率 100% 表示干擾問題。
套用 [ 依進程使用率]、[執行緒 ] 預設，然後依第一個 [就緒 (我們) ] 資料行排序。 (這是包含 Sum aggregation.) 的資料行
展開受影響的活動程式，並查看重要路徑上執行緒的就緒時間。 此值是解決任何執行緒干擾問題可減少延遲的最大時間。 相對於所調查延遲的顯著性值，表示執行緒干擾問題存在。
圖 39 CPU 使用率接近 100%，圖 40 執行緒干擾問題代表此案例：
圖 39 CPU 使用率接近 100%
圖 40 執行緒干擾問題
調查
識別問題之後，您必須判斷受影響的執行緒為何花費太多時間處於就緒狀態。
技術：判斷線程花費的時間處於就緒狀態的原因
您可以使用 CPU 使用量 (精確) 圖形來判斷線程在就緒狀態中花費的時間的原因。 您必須先判斷線程是否受限於特定處理器。 雖然您無法直接取得這項資訊，但您可以在高 CPU 使用率期間檢查執行緒的 CPU 使用量歷程記錄。 這是執行緒通常會在處理器之間切換的期間。
判斷線程的處理器限制
縮放至受影響的區域。
新增 CPU 使用量 (精確) 圖形，並 套用依進程、執行緒 預設的使用率。
使用 [進階] 對話方塊，在NewThreadId右側新增具有唯一計數匯總模式的Cpu資料行。
篩選圖表，只顯示您感興趣的執行緒。
Cpu資料行中的值會反映執行緒在目前時間間隔內執行的處理器數目。 在 100% CPU 使用率的期間，此數目大約是允許執行此執行緒的處理器數目。 如果值小於可用的處理器數目，執行緒可能受限於特定 CPU。
圖 41 受限制的執行緒提供此圖表的範例：
圖 41 受限制的執行緒
在您知道執行緒的處理器限制之後，您可以判斷哪些先占或耗盡執行緒。 若要這樣做，您必須識別執行緒花費在就緒狀態的間隔，然後檢查那些間隔期間執行的其他執行緒或進程。
判斷哪些優先或耗盡執行緒
建構圖表，顯示執行緒處於就緒狀態，並套用依 進程、執行緒 預設的使用率。
開啟 [ 檢視編輯器]，按一下 [ 進階]，然後選取 [ 圖形組態 ] 索引標籤。
將 [開始時間 ] 設定為 [ReadyTime] (s) ，並將 [ 持續時間 ] 設定為 [就緒 () ]，如圖 42 [就緒時間資料行] 所示。 按一下 [確定]。
圖 42 就緒時間資料行
在檢 視編輯器中，將 [CPU 使用量] (%) 資料行取代為 ) [就緒 ([Sum] 資料行。
選取感興趣的執行緒，以產生類似圖 43 就緒時間圖形的圖形：
圖 43 就緒時間圖表
在此情況下，執行緒花費大量時間處於就緒狀態。 若要判斷其一般優先順序，請將 Average 匯總新增至 NewInPri 資料行。
在此情況下，執行緒的平均優先順序完全是 8。 這個數位表示它可能是永遠不會收到優先順序提高許可權的背景執行緒。
已知平均優先順序之後，請查看允許執行緒執行之 CPU 的 CPU 活動。
在此情況下，執行緒決定只有 CPU 1 的親和性。
新增另一個 CPU 使用量 (精確) 圖形，並 依 CPU 預設套用使用率。 選取相關的 CPU。
開啟 [ 進階 ] 檢視，並針對您稍早找到的優先順序新增篩選，以篩選出該執行緒。 圖 44 執行緒篩選中顯示此案例：
圖 44 執行緒篩選
在圖 45 CPU 使用量、就緒時間和其他執行緒活動中，頂端圖表顯示執行緒 3548 的 CPU 使用量。 中間圖表會顯示執行緒就緒的時間，而底部圖表會顯示執行緒允許執行 (在此案例中，Cpu1) 的活動。
圖 45 CPU 使用量、就緒時間和其他執行緒活動
放大執行緒已就緒但未執行的區域，以在間隔期間的大部分時間。
在 [CPU 使用量 ] 圖表中，將 NewInPri 新增至列左側，並檢查結果。
優先順序等於目標執行緒優先順序的執行緒或進程會顯示執行緒已耗盡的時間。 優先順序高於目標執行緒優先順序的執行緒或進程，會顯示執行緒被先占的時間。 您可以藉由新增所有先占執行緒和動作的時間，來計算執行緒被佔用的總時間。
圖 46 依優先順序使用當目標執行緒就緒時，顯示已先占執行緒時間的 730 毫秒，而執行緒時間的 300 毫秒已耗盡。 (此圖會縮放至 1192ms 間隔。)
圖 46 依優先順序設定目標執行緒就緒時的使用量
若要判斷哪些執行緒負責先占和耗盡此執行緒，請將 NewProcess 資料行新增至 NewInPri 資料行右邊，並檢閱進程執行所在的優先順序層級。 在此情況下，先占和耗盡主要是由相同進程中的另一個執行緒和TestResidentApp.exe所造成。 您可以假設這些進程會收到高於其基底優先順序的定期提高優先順序。
解決方案
您可以藉由變更組態或元件來解決先占或耗盡問題。 請考慮下列補救方式：
從系統移除有問題的進程。
調整有問題進程的基底優先順序...
變更有問題的進程執行的時間;例如，延遲電腦重新開機時的開始時間。
如果問題元件可以變更，請重新設計它們，使其耗用較少的 CPU，或以較低的優先順序執行。
DPC/ISR 干擾
當執行 DPC 和 ISR 耗用過多處理器時間時，可能沒有足夠的可用 CPU 時間可供執行執行緒。 這種情況可能會導致執行緒干擾的類似延遲。 當執行緒必須以一般高頻率速率完成作業時，例如在視訊播放或動畫中，DPC 和 ISR 的干擾可能會導致操作問題。
問題識別
許多評量都使用啟發學習法來識別 DPC/ISR 相關問題。 當 DPC/ISR 活動回報為下列格式的問題時，會將其識別為可疑：
DPC D超過P期間x毫秒的閾值。此 DPC 的n個實例會針對總計t毫秒執行。
其中 D 是 DPC， m 是設定閾值的毫秒數， x 是 DPC 超過閾值的次數， P 是目前的進程， n 是 DPC 執行的實例數目， 而 t 是 DPC 超過閾值的毫秒數。
例如，評量會報告下列問題：
DPC sdbus.sys！SdbusWorkerDpc 超過媒體引擎存留期期間 3.0 毫秒 153 次的目標。 此 DPC 的 153 個實例總共執行 864 毫秒
如果針對顯示問題事件或延遲的活動回報此問題，則 DPC/ISR 活動可能是原因。
手動識別 DPC/ISR 干擾
若要手動識別 DPC/ISR 干擾，請在 WPA 中開啟追蹤，並識別感興趣的問題事件。 這些是評定特定的泛型事件，例如 Microsoft-Windows-Dwm-Core：SCHEDULE_GLITCH 或 Microsoft-Windows-MediaEngine：DroppedFrame。
在事件的圖表旁邊，新增 DPC/ISR Duration by CPU 圖表。 如果 依 CPU 的 DPC/ISR 持續時間 尖峰與問題事件一致，DPC/ISR 可能是造成問題的因素。
如需其他資料，請放大數個問題事件顯示前 100 毫秒發生的時間週期。 如果在發生問題事件之前，在 100 毫秒區域中的一或多個處理器上顯示重要的 DPC/ISR 活動，您可以判斷問題事件是由 DPC/IRS 活動所造成。
若要判斷 DPC/ISR 干擾是否造成延遲，請將縮放至顯示執行中線程的區域。 記下此執行緒執行所在的 CPU 或 CPU。
在 DPC/ISR 圖表中，依 CPU 預設套用 DPC/ISR 持續時間 ，並在該時間範圍內的相關 CPU 上檢視 DPC/ISR 活動。
圖 47 問題事件和 DPC/ISR 活動顯示iexplore.exe執行緒 864 與受影響的活動有關。 執行緒 864 處於 CPU2 上執行狀態，檢視中時間範圍的 10.65%。 不過，DPC/ISR 圖表顯示 CPU2 正忙於執行 DPC/ISR 10% 的時間。
注意 大部分的 DPC/ISR 沒有如本範例所示的高影響。
圖 47 問題事件和 DPC/ISR 活動
在圖 48 DPC/ISR 與問題事件無關時，會顯示 DPC/ISR 與效能問題無關：
圖 48 DPC/ISR 與問題事件無關
在圖 49 DPC/ISR 干擾所造成的延遲中，會顯示 DPC/ISR 造成效能問題：
圖 49 DPC/ISR 干擾所造成的延遲
調查
在您判斷 DPC/ISR 與問題或延遲有關之後，您必須判斷涉及哪些特定的 DPC/ISR，以及其發生頻率過長或執行的原因。
技術：檢閱Assessment-Reported DPC/ISR 問題
在評估回報的 DPC/ISR 問題中，您可以展開問題，以顯示 DPC 或 ISR 先占的主要程式。 展開堆疊，以檢視與受影響活動最相關的進程 DPC 活動，如中所示，展開堆疊以瞭解 DPC 的作用。 圖 50 展開的 DPC 堆疊顯示展開的堆疊：
圖 50 展開的 DPC 堆疊
技術：尋找最高持續時間的 DPC/ISR 並檢閱堆疊
如果評量未回報 DPC/ISR 為問題，您可以使用 DPC/ISR 和 CPU 使用量 (取樣) 圖形，以取得最相關的 DPC 的堆疊資訊。 建議您尋找感興趣的 DPC/ISR、記下其模組和函式，然後在 CPU 使用量 (取樣) 圖形中找到範例，以取得完整的堆疊資訊。
尋找最高持續時間的 DPC/ISR 並檢閱堆疊
縮放至感興趣的間隔。
在 DPC/ISR 圖表中，選取預設 的 DPC/ISR 持續時間 by Module， Function。
如果載入符號，DPC/ISR 事件會依總持續時間排序，然後依 Module 和 Function 細分。 清單中的頂端資料列包含可能導致事件問題的 DPC/ISR 事件。 記下模組和函式名稱。
在 [ CPU 使用量 (取樣) 圖表中，選取 [依進程 使用量] 預設。 根據預設，此預設會隱藏 DPC/ISR 活動。
開啟 [ 檢視編輯器]，然後按一下 [ 進階]。
在 [ 篩選] 索引標籤上，將 [ 隱藏符合篩選準則的資料列 ] 設定變更為 [保留符合篩選的資料列]。 這可讓 DPC/ISR 活動顯示。
移除 [處理] 資料行，並新增 [堆疊 ] 資料行，以檢視依堆疊排序的 DPC/ISR。
清除目前的資料列選取範圍。
以滑鼠右鍵按一下 [堆疊 ] 資料行中的儲存格，然後按一下 [在此資料行中尋找]。
輸入您在此程式的步驟 2 中所記錄的模組和函式。
核取 [新增至目前的選取範圍]，然後按一下 [ 尋找全部 ] 以選取函式的所有實例。
選取所有資料列之後，按一下滑鼠右鍵，然後按一下 [ 批註/檢視呼叫者]。
此檢視會顯示此特定函式的活動，依總持續時間排序。 此檢視類似于評估回報問題的詳細檢視中顯示的堆疊。 Weight資料行會近似堆疊上每個函式所花費的內含時間，以毫秒為單位。
此檢視顯示在依近似持續時間排序之 DPC 的圖 51 呼叫者中：
圖 51 依近似持續時間排序的 DPC 被呼叫者
技術：檢閱 Long-Running DPC/ISR
DPC/ISR 的總持續時間很重要，但長時間執行的個別 DPC/ISR 可能會造成延遲。 在 DPC/ISR 圖表中， [內含持續時間] (ms) 資料行，依遞減順序排序，顯示個別 DPC/ISR 的最大持續時間。 某些評定設定檔中可用的預設 Long DPC/ISR 可讓您篩選此檢視，只顯示具有大於 1 毫秒的內含持續時間的 DPC/ISR。
注意 如果無法使用此預設，您可以開啟 [ 檢視編輯器][ 進階 ] 區段以新增篩選。
解決方案
DPC/ISR 活動通常反映必須在硬體或元件層級更正的硬體或軟體問題。 在設定層級，您可以取代硬體，或將相關的驅動程式升級至固定版本。 在元件層級，硬體和驅動程式應遵循 MSDN 中 DPC/ISR 的最佳做法，並盡可能使用執行緒式 DPC。 執行緒的 DPC 不會在用戶端版本的 Windows 分派層級執行。 如需 DPC/ISR 最佳做法的詳細資訊，請參閱 ISR 和 DPC 行為的指導方針和執行緒 DPC 簡介。