第二章 效能測量&分析概述(Performance Measurements & Analysis in a Nutshell)

在上一章中，我們研究了為什麼效能很重要，甚至診斷了一個簡單的效能問題。在本章中，我們將總覽執行效能分析的其他方法。為了證明這些問題，我們將診斷與練習1.1中調查的相同問題。我們還將對比這些不同的方式，並回顧它們的利弊。然而，在冒險通過這些替代方案之前，讓我們首先更好地瞭解衡量時間的實際含義。

測量時間(Measuring time)

測量時間是所有與效能相關的工作的核心。效能分析旨在優化兩個關鍵維度的系統執行：

• 執行場景所需的時間
• 系統執行這些情景的能力，也稱為容量

當然，第一項要求我們能夠測量時間間隔。正如我們將看到的，第二項也需要時間測量。在當代計算機系統上，有許多不同的方法可以測量時間，從基於秒錶的粗製濫造測量，到基於高精度高頻效能計數器的測量。

測量場景持續時間的最簡單、最天真的方法之一是使用常規秒錶（stopwatch）。正如您可以想象的那樣，這種方法缺乏準確性，而且非常勞動密集型——例如，嘗試用秒錶測量計算機啟動幾十次所需的時間（以獲得統計準確性），您很快就會意識到這種方法不具備擴充套件性。此外，秒錶不足以測量需要毫秒級精度的場景。即使是我們中最優秀的人，在使用秒錶時，通常也不能精確地記準時間。幸運的是，有更好的方法來衡量和報告場景持續時間。

大多數剛接觸效能工程的人都是從使用秒錶般的方法測量場景的持續時間（例如使用者互動的響應性）開始的。當然，這隻適用於要花相當長時間的場景，這種場景一般都會給使用者展示進度條。顯然，對於足夠快的場景（例如響應式使用者互動），依賴人類感知的測量方法根本不起作用。特別是，手動秒錶測量中涉及的誤差通常與您想要測量的活動具有相同的數量級。不過，秒錶測量是你經常使用的東西，因為它的簡單性和缺乏更好的工具。秒錶的精度在用於驗證較長執行場景的問題時有時仍然可以接受，。

即使在秒錶接近精度可能足夠的場景中（即測量延長場景時），您仍然需要確保統計的健全性。您可以通過多次測量場景延遲，然後計算中位數和百分位數來實現此目的。解決此問題的一種常見方法是編寫測量的工作流指令碼，並在指令碼中的正確點包括時間戳探測器。在Windows的指令碼環境中，您可以在CMD控制檯執行%time%

雖然從技術上講，系統時間精度應該足夠好，可以測量需要300-500毫秒的場景，但由於實際執行這些系統命令的成本和解釋命令提示符環境的開銷，從指令碼中這樣做是不實際的。要測量<300~500ms精度的場景，您需要在程式碼中加時間統計程式碼，而不再能通過指令碼來測量。(即在程式碼中的興趣點新增時間戳標記）。系統時間可以在程式碼中使用，但正如我們稍後將向您展示的那樣，對於許多感興趣的場景，您確實希望通過使用所謂的高精度時間源獲得更精確的時間。

注意：正如我們稍後將更正式地看到的那樣，300-500ms處於系統可視響應使用者輸入的可接受響應時間的上限。有些人把這叫做足夠快，而另一些人則說這差點沒響應。由於這本書的重點是確保使用者體驗非常快速和快速（當然，在使用者的腦海中瞬間將是理想的目標），我們顯然需要一種方法來精確測量短於300ms的時間間隔。

計算機系統中有很多東西可以跟蹤時間。根據系統架構，您可能會遇到ACPI計時器、PM計時器、CMOS計時器、HPET計時器等時間源。這些時間源統稱為硬體計時器。處理器本身還提供TSC（時間戳計數器）時間測量工具，可通過讀取時間戳計數器（RDTSC）指令訪問該工具。在測量時間時，您通常不會直接接觸到這些時間源。然而，作業系統確實利用它們來實現各種時間測量API，用於系統時間和高精度時間測量。

注意：在.NET中，測量時間的常見方法是使用System.Dias.StopWatch類。請注意，此類不保證高精度測量——此類支援是系統特定的。要檢查StopWatch類是否確實為您提供了高精度時間測量，您可以使用以下C#程式碼：

System.Diagnostics.StopWatch( (IsHighResolution==TRUE) ? QPC : SystemTime)

將測量場景的持續時間對映到測量它們所需的測量精度，並列舉典型執行環境的相應Windows API和命令，得到下面的圖示

正如你所看到的，秒錶測量只涵蓋了非常小的場景範圍。人眼顯然對它可以記錄的場景持續時間有一個下限。同時它可以跟蹤的場景的持續時間也有上限。超出這一時間範圍的情景（即非常快的情景<2s或相對緩慢的情景>5min）不適合取決於人類反應的測量。

為了解決人類對反應時間和注意力範圍的限制，我們可以依靠自動化。通過指令碼獲取的時間測量足夠好，可以測量超過一秒鐘的時間跨度。精度如果要求更低的話，則從指令碼中呼叫時間測量命令的時間就會開始影響您的測量。為了更精確，您需要在程式碼中新增計時程式碼。檢視圖2.1，您可以看到，通過眾多列出的API提供的系統時間可以讓您精確到數百毫秒，或者比指令碼好一個數量級。如果您想獲得更精確的資訊，您需要使用利用高精度時間源的API，通常稱為QPC（QueryPerformanceCounter Win32 API的縮寫）。

注意：從歷史上看，當CPU以MHz頻率執行時，系統時間的精度“足夠好”。隨著時鐘速度快得多的CPU的引入，系統時間精度不足以測量更高精度的微活動。雖然您仍然可以使用系統時間來測量一些邊緣響應場景（即測量300-500ms的持續時間），但是如果僅依賴系統時間精度，再想將此類場景的持續時間分解為更細節的基礎子活動就面臨困難。因此，您將看到我們在本書中大量利用了更精確的QPC時間源。

你說，為什麼系統時間和QPC都要測量時間？系統時間表示每個人都習慣的日曆時間。這使得日誌中的發生時間能夠對映到日常人類活動。另一方面，QPC從系統通電開始計數，並且與日曆時間沒有相關性(儘管您可以使用上次引導系統時間來對映QPC時間到日曆時間）。因此，兩者都有他們的用途。系統時間為您提供日曆時間上下文，而QPC時間提供更高精度的測量。

注意：在Windows 8中，通過引入WDK KeQuerySystemTimePrecise()和Win32 APIGetSystemTimePreciseAsFileTime()，系統時間的API精度得到了提高，更多詳細資訊，請參閱MSDN。

個人補充：初步看了下MSDN， Win32 API GetSystemTimePreciseAsFileTime最大的作用是用於高精度測量，且需要關聯絡統時間的場景。

眾所周知，業內許多成熟的程式碼庫在其自定義測量中仍然依賴於系統時間。正如我們稍後將看到的，那些選擇使用ETW的實現可以在這些時間源之間輕鬆切換，而無需任何程式碼更改。

現在我們已經討論瞭如何測量時間，接下來讓我們看看Windows附帶的許多效能監控工具，看看如何使用它們來解決我們在第1章中討論過的問題。

使用Windows內建工具識別CPU飽和問題（Identifying CPU saturation using Windows inbox performance tools）

回憶一下我們在第1章練習1.1中回顧過的效能問題的基本示例。在該練習中，我們能夠定位導致系統執行緩慢的原因是CpuHoger.exe導致了CPU飽和。為了收集證據，我們使用WPR捕獲ETL跟蹤，然後依靠WPA來確定罪魁禍首程序。

對於由單個程序導致的如此簡單的CPU飽和的場景，實際上還有其他內建工具(它們與Windows捆綁在一起)可以定位該場景。讓我們利用這個機會回顧一下其中的一些。如果您熟悉這些工具及其侷限性，請隨時跳過這些練習

工作管理員(Task Manager)

工作管理員隨Windows一起提供，是最常用的面向終端使用者的工具，旨在識別和幫助緩解典型的飽和來源（例如，通過終止故障程序或降低其執行優先順序緩解系統卡慢）。工作管理員從XP到Windows 7基本上沒有變化，在Windows 8中經歷了相當大的演變。特別是，“效能”選項卡已完全重新設計，以近乎實時地顯示關鍵系統性能指標（KPI）（即資源使用情況可以每秒鐘更新一次）。這些指標包括CPU、記憶體、儲存和網路。

練習2.1 使用工作管理員識別CPU飽和問題

概述

在本練習中，我們將使用Windows 8版本的工作管理員。讓我們看看當我們執行CpuHogger.exe時，工作管理員會顯示什麼。

分析方法

本節介紹如何使用工作管理員定位導致系統卡慢的程序。

1. 開啟工作管理員

2. 切換到詳細資訊介面

3. 切換到效能標籤頁

4. 執行CpuHogger.exe

5. 我們可以觀察到系統變得未響應，當重新可以響應是你將看到一個類似下圖的凸起。
   

6. 請注意，在CpuHoger.exe執行時，您無法與工作管理員互動。一旦CpuHoger.exe停止執行，工作管理員再次變得響應，我們看到CPU實際上在其無響應的時間間隔內飽和。不幸的是，工作管理員是一個實時監測工具，沒辦法回到過去檢查是哪個具體程序導致的。你必須在出問題的過程中找到罪魁禍首。

7. CpuHoger碰巧使用應用程式可用的最高執行優先順序，而工作管理員以預設優先順序執行，因此出現問題時它也沒有響應。我們將在第9章更多地討論執行優先順序。目前，請記住，優先順序較高的程序比優先順序較低的程序獲得更多的CPU時間。

8. 通過將工作管理員切換為以實時優先順序執行，我們可以使它以比CpuHoger更高的優先順序執行。這將使我們能夠使用其GUI識別罪魁禍首程序。要將工作管理員切換為實時優先順序執行，請右鍵單擊“詳細資訊”選項卡中的條目，選擇“設定優先順序”，然後選擇“實時”，如圖2.3所示。
   

9. 現在，我們已經確保了工作管理員以實時優先順序執行，讓我們來看看誰消耗了最多的CPU時間。為此，請通過單擊“詳細資訊”選項卡中的“CPU”列的標題，按降序排序

10. 現在，讓我們新增基本優先順序列，以檢視哪個程序以什麼優先順序執行。為此，右鍵單擊標題，選擇選擇列，然後選擇基本優先順序，如圖2.4所示。
    

11. 再次執行CpuHogger.exe

12. 您應該看到類似於圖2.5中所示的內容。也就是說，當CpuHoger.exe執行時，它被列在詳細資訊列表的頂部，佔用99%的CPU時間。請注意，Taskmgr.exe以實時優先順序執行，而CpuHoger.exe以正常優先順序執行。這確保了我們能夠與工作管理員互動，即使CpuHoger使CPU飽和。
    

    注意：為了確保CPU飽和，CpuHoger將其工作執行緒的優先順序提高到最高可用的非實時優先順序——即優先順序15。當我們將工作管理員設定為以實時優先順序執行時，它的執行緒以24到26的優先順序執行，這要高得多，使它能夠保持響應。執行緒執行優先順序不是您可以在工作管理員中看到的。在第9章中，我們將向您展示如何在WPA中檢視此資訊。

13. 您還可以通過單擊程序選項卡觀察CpuHoger.exe的高CPU使用率。圖2.6顯示了一個與您將在那裡看到的類似的檢視。請注意，在檢視CPU以外的資源飽和時，“程序”選項卡可能很有用。
    

小結

在本示例中，我們已經向您介紹瞭如何使用工作管理員識別導致CPU飽和的罪魁禍首程序。為了確定實際程序，我們必須將工作管理員提升到實時優先順序，並在問題發生時捕獲問題。工作管理員不提供記錄工具和離線分析功能，使其有用性僅限於幫助識別持續的CPU飽和問題.

正如我們剛才看到的，工作管理員基本上提供了反映系統活動的實時檢視

注意：工作管理員預設使用的1秒1次的正常更新速率，在高更新速率下以0.5秒更新一次，在低更新速率下以4秒更新一次，您可以檢視從30秒（高更新頻率）到4分鐘(低更新頻率)的總CPU使用率的整體趨勢圖。

當然，這裡的關鍵限制是，要檢視哪些程序導致了高CPU使用率，我們需要監控問題發生時正在更新的列表，這並不總是實用的。為了更好地檢視當時發生的事情，我們可以使用另一個內建工具，稱為資源監視器。在下面的練習中，我們將使用該工具對同一問題進行分析。

資源監視器(Resource Monitor)

雖然工作管理員提供了對系統性能的基本描述，但對一個展現關鍵系統資源的活動細節的檢視通常是問題診斷所必需的。為了滿足這一需求，資源監視器已新增到Windows Vista中的作業系統中。雖然此工具從一個版本到另一個版本一直在發展，但其關鍵功能集在Windows 8中基本上保持不變。

練習2.1 使用資源監視器識別CPU飽和問題

分析方法

1. 通過工作管理員“效能”選項卡頁下面的按鈕開啟資源監視器，或者命令列執行perfmon.exe /res開啟

2. 與工作管理員不同，資源監視器保持跟蹤完整1分鐘的CPU活動，因此即使您無法實時觀察問題，您仍可以在一分鐘時間視窗內看到問題。

3. 可選：與上一個練習一樣，您可以使用工作管理員提高資源監視器的優先順序。為此，請在工作管理員的“詳細資訊”選項卡中顯示的程序列表中找到PerfMon.exe，並將其CPU優先順序設定為實時（有關如何執行此操作的示例，請參閱圖2.3）。請注意，檢視CPU使用歷史記錄和識別罪魁禍首程序不需要這樣做，但只有當我們提高資源監視器的優先順序時，才能在CpuHoger.exe執行時實時觀察CPU使用峰值。

4. 執行CpuHogger.exe

5. 請注意，系統變得無響應。如果您提高了資源監視器的優先順序，您會注意到它將繼續更新自己，因為它的執行優先順序高於CpuHogger.exe。如果您沒有，它將顯示掛起，就像工作管理員一樣，直到CpuHoger.exe完成，但隨後將重新整理並顯示CPU使用情況。

6. 在CpuHogger.exe退出後，你應該可以看到類似圖2.7顯示的情況：
   

7. 正如您所看到的，CpuHoger位於列表的頂部，在其生命週期內平均佔總CPU利用率的55%，如“平均CPU”列中所示。這是迄今為止列表中最高的CPU使用者。

注意： 從資源管理器中看到CPU一列的CpuHoger.exe的CPU使用率為23%，它表示從上次採集到此次期間的CPU使用率。預設情況下，資源監視器使用1s取樣頻率。

8. 資源監視器還附帶了用於關鍵系統資源的專用選項卡，包括CPU。在CPU選項卡中觀察CpuHogger.exe時，您將看到與2.8所示類似的內容
   

9. 請注意，在CPU選項卡中，除了CPU總體使用情況外，您還可以檢視系統上每個邏輯核的CPU歷史記錄。由於CpuHoger.exe使所有可用的邏輯處理器飽和，因此我們可以看到系統上所有邏輯處理器的CPU利用率相似。

注意：通過觀察每個CPU核利用率檢視， 可以更容易看到為什麼CpuHogger.exe的平均使用率大概為53%。（這裡感覺看總體的話，在1分鐘的週期內，肯定沒有佔到53%。 那是不是意味著，聯絡到上面的採集週期是1s1次，因此猜測比如這個程式執行15s，那麼在這15s的取樣週期內，CpuHogger.exe大概會佔53%多的CPU時間片，應該資料是由此而來。）

小結

在本示例中，您已經學習瞭如何使用資源監視器識別導致CPU飽和的罪魁禍首程序。與工作管理員不同，不需要將資源監視器提升到實時優先順序，因為它可以記錄過去60s的歷史記錄。不過，與工作管理員類似，資源管理器也不提供記錄工具和離線分析功能，它侷限於幫忙分析在程式執行的最近1分鐘內的CPU飽和問題。

正如我們剛才看到的，資源監視器提供了一個基本的一分鐘跟蹤檢視，以瞭解系統活動。您可以使用另一個名為Performance Monitor的內建工具進一步進行此分析。在以下練習中，我們將使用效能監視器分析同一問題。

效能監視器(Performance Monitor)

雖然工作管理員和資源監視器提供了對系統性能的基本觀察見解，但在分析已經發生的事情時，您通常不想倉促行事。事實上，在許多情況下，你甚至不在那裡實時看到它。當然，有時您也沒有對有關計算機的物理（甚至遠端）訪問許可權。顯然，離線效能分析的需要可能至關重要。要實現離線效能分析，我們需要能夠以效能跟蹤（例如日誌）的形式收集證據。

實際上，當我們捕獲ETL檔案時，我們已經在練習1.1中成功地收集了一個這樣的Trace。此效能跟蹤日誌幫助我們診斷CpuHoger.exe的CPU飽和問題。正如我們之前提到的，Windows附帶了兩個互補的檢測平臺，形式是Windows效能計數器(PCW)和Windows事件跟蹤(ETW)。當我們在第1章的練習1.1中捕獲ETL跟蹤時，我們使用ETW平臺進行效能測量。現在，我們來回顧一下如何利用PCW來診斷該問題。

早在Windows 95, Windows就與一個專門用於效能監控的工具捆綁在一起。該工具最初稱為系統監視器（SysMon.exe），在Windows 2000中被重新命名為效能監視器(PerfMon.exe)。它構建在PCW之上，允許您跟蹤特定效能計數器（如CPU和磁碟利用率）隨時間推移的值。在過去幾十年裡，多個應用程式、服務和驅動程式也提供了自己的效能計數器。PerfMon現在通常用於在大時間跨度內監控系統的效能。

接近實時監控的效能監視器

預設情況下，效能監視器近乎實時地跟蹤當前活動。具體來說，您可以看到您選擇監控的PCW計數器的最近100秒的資料。這與我們在工作管理員和資源監視器中看到的檢視相似。在下面的練習中，讓我們嘗試將此監控功能用作CPU飽和診斷工具。

練習2.3 通過效能監視器的當前活動檢視監控CPU飽和問題

分析方法

本節介紹用於使用Performance Monitor的當前活動檢視確定導致系統上出現卡慢的罪魁禍首程序的分析工作流程。

1. 開始選單開啟效能監視器

2. 開啟效能監視器圖表工具，如圖2.9所示
   

3. 請注意，此檢視顯示了隨時間推移的總處理器利用率。在近乎實時的觀察模式下執行時，PerfMon會顯示選定效能計數器的100秒後的值。預設情況下，已選擇%Processor Time ,會預設展示CPU時間趨勢

   注意：與工作管理員和資源監視器不同，它們在顯示圖形資訊時利用檢視平移，效能監視器在顯示新資料時迴圈覆蓋以前的資料

4. 現在，讓我們通過執行CpuHoger.exe來重現效能問題。在應用程式完成其邪惡行為後，您將看到一個類似於圖2.10所示的檢視。
   

5. 我們現在知道CPU已經飽和，但我們還不知道是哪個程序造成的。要找出答案，讓我們嘗試使用“每個-程序“效能計數器。

6. 點選新增按鈕或者快捷鍵Ctrl+Shift+N，開啟類似2.11所示介面：
   

7. 此檢視顯示系統上所有可用的效能計數器，按效能計數器組分組。要開始顯示實際計數器隨時間推移的值，您需要將該計數器的例項新增到右側列表框中。

8. 找到Process選項卡，只選擇% Processor Time觀察程序的CPU時間，然後在下面的框中選擇所有程序，然後新增。
   

9. 略，包含在8步裡了

10. 由於例項是按字母順序列出的，CpuHoger應出現在conhost#2和csisyn~1之間。但是，正如您可能注意到的，CpuHoger.exe沒有列出在那裡，如圖2.12所示。這並不奇怪，因為我們還沒有啟動它。、

11. 新增所有例項。

12. 單擊確定，然後執行CpuHoger.exe。您最終看到的內容將與圖2.14中所示的檢視相似。請注意，我們可以選擇加號右邊的右邊的畫筆按鈕突出顯示選定的資料行，重點關注處理器的總使用情況。
    

13. 請注意，總處理器使用率如預期的那樣上升，但沒有特定程序的CPU使用率隨之上升。事實上，您可以看到，在_7:12:38PM和7:12:58PM期間，其他程序的CPU使用率降低了。只有當總CPU使用率從100%開始下降時，我們才會看到其中一些程序以持續到晚上7:13:05的突發形式恢復其CPU使用率模式。

注意：正如我們稍後將瞭解的那樣，這被稱為CPU匱乏，CpuHoger.exe阻止了所有其他活動取得應有的進展。

14. 顯然，如果沒有一些程序實際耗盡CPU，總CPU使用率不太可能在大約20秒內躍升到100%。我們知道這是哪個程序，因為我們自己啟動了它，但檢視捕獲的程序列表，您不會在其中找到CpuHoger.exe。這是PerfMon的一個已知限制，它在監視<所有例項>處理器計數器時不跟蹤新啟動的（即臨時）程序。

注意：此限制僅存在於PerfMon的實時監控功能。正如我們稍後將看到的，它不會影響PCW跟蹤到BLG檔案。

小結

在本示例中，我們試圖使用效能監視器識別導致CPU飽和的罪魁禍首程序，但再次遇到了工具的限制。具體來說，我們不能使用效能監視器的實時觀察檢視，因為它無法監視在監視開始後才執行的程序。

效能監視器已經存在了近20年（截至本書撰寫時），效能計數器生態系統非常活躍。雖然自Windows 2000以來，PerfMon的UI沒有進行重大投資，但該工具仍在許多伺服器監控場景中廣泛使用。如果您想了解更多關於PerfMon的資訊，您只需要線上搜尋。

效能監視器離線BLG日誌分析(Performance Monitor offline BLG trace analysis)

在上一個練習中，我們嘗試通過PerfMon的實時監控功能使用PCW診斷CpuHoger.exe導致的CPU飽和。不幸的是，我們沒有成功，因為PerfMon的當前活動檢視不跟蹤新啟動的程序。但是，有一種可以利用PCW平臺的方法來診斷此問題，即使用PerfMon的離線分析功能，以BLG（Binary Log ：二進位制日誌）跟蹤的形式。

練習2.4 通過效能監視器的離線BLG日誌分析CPU飽和問題

日誌採集方法

本節介紹了收集資料所需的資料收集工作流，然後我們將使用這些資料來確定導致您在系統上經歷的卡慢的原因。

1. 啟動效能監視器

2. 展開左側的資料收集器集(Data Collector Set)專案，然後右鍵單擊使用者定義(User Defined)專案，然後單擊新建|資料收集器集選項，如圖2.15所示。
   

3. 讓我們將此資料收集器集稱為“CPU使用率”，選擇手動建立（高階），如圖2.16所示，然後單擊下一步
   

4. 下一步選擇效能計數器， 繼續點選下一步， 如圖2.17
   

5. 在下一頁上，單擊新增...新增以下三個計數器，新增的過程和上一個練習中描述的過程類似：

\Process(*)\% Processor Time
\Processor(_Total)\% Processor Time
\Processor Information(_Total)\% Processor Utility

6. 完成後，將取樣間隔設定為一秒。完成後，您應該看到一個類似於圖2.18所示的檢視。
   

7. 後面只需單擊“完成”作為下一步。然後，您應該看到在使用者定義資料夾下建立的CPU使用量資料收集器集，如圖2.19所示。請注意，在左側的“報告”節點下還建立了使用者定義的\CPU使用情況報告資料夾。一旦我們收集了測量報告，我們就會在這裡找到報告。
   

8. 右鍵單擊CPU佔用率，然後選擇Start，啟動新建立的資料收集器集，如圖2.20所示。
   

9. 在收集的過程中，執行CpuHogger.exe

10. 請注意，系統再次變得無響應，但這應該不再是一個問題，因為我們現在正在後臺記錄系統活動。

注意：正如您將看到的，由於CpuHogger.exe的自大狂性質，它可能從PerfMon的資料收集中竊取CPU時間片，因此您可能仍然會丟失一些資料，

11. 在CpuHogger.exe退出後，再次右鍵CPU使用率資料收集器並點選停止

分析方法

1. 展開報告\使用者定義下的CPU使用率資料夾以查詢新生成的報告。雖然您的檢視將有所不同，但您仍然可能在測量中看到間隙，總體使用率類似於圖2.21所示。
   

2. 現在，讓我們新增每個程序%Processor Time計數器的All instances，以嘗試查詢違規程序。您會注意到，新增它們雖然仍然存在部分時間段無法看到資料的問題，如圖2.22所示，但您可以看到CpuHoger.exe確實列在這些程序中，並且它在成功獲取資料的時間範圍內消耗了100%的CPU，如預期的那樣（在100的頂部的一條小橫線，圖上不太好看）。
   

3. 造成這些差距的原因是PCW是一個輪詢基礎架構，其中輪詢程式碼在使用者模式下執行（應我們的請求啟動以收集測量資料）。此執行以正常優先順序進行。由於CpuHoger.exe以更高的優先順序執行，它可以阻止PerfMon的資料收集取得進展。前面我們嘗試使用工作管理員和資源監視器時，我們已經遇到了這個問題。

4. 不幸的是，在這種情況下，提高PerfMon UI應用程式（託管在mmc.exe中）的優先順序並不能解決問題。實際上，計數器輪詢發生在不同的程序（rundll32.exe）中，該程序為每個資料收集器集執行單獨啟動。

5. 要使用“手動優先順序提升”方法消除測量中的差距，我們必須先開始資料收集，在工作管理員中找到用於資料收集的rundll32.exe的特定例項，然後將其優先順序提升到實時。然而，有多個rundll32.exe例項的情況並不罕見。找到對的程序可能是一個挑戰，而且在實踐中我們並不建議這樣做。

6. 如果我們真的這樣做了，Gap就會消失，如圖2.23所示。雖然您可以嘗試確認這一點，但我們實際上不建議將“手動優先順序提升”作為效能衡量方法。特別是，通過將程序提升到高優先順序，您可能會影響你試圖測量的場景。我們這麼嘗試只是為了更好地理解基於PCW的資料收集的侷限性
   

注意：PCW從使用者模式程序中取樣，因此很容易受到CpuHoger等自大狂程序的影響。與PCW不同，ETW從系統自身內部收集資料，不受此類問題的影響。在下一節中，我們將更仔細地瞭解切換到ETW進行效能測量的好處。

小結

在本示例中，我們再次嘗試使用效能監視器識別導致CPU飽和的罪魁禍首程序。我們沒有使用其實時介面，而是依賴其對使用使用者定義的Data收集器集捕獲的BLG檔案的離線分析，這使我們能夠跟蹤新啟動的程序（包括CpuHoger.exe）的效能計數器。請記住，通過近乎實時的監控，我們無法跟蹤新啟動的程序

不幸的是，我們再次遇到了以正常優先順序收集資料的限制，即它被CpuHogger.exe這種更高優先順序的問題程序搶佔了時間片。這導致了在我們需要的時候，我們的測量出現了偏差。然而，我們仍然可以瞥見CpuHoger.exe貢獻的高CPU使用率。 並且通過提高基礎收集程序的優先順序（我們不建議您實際中這樣做）來確認這一點。

資料收集器集可以成為效能監控的強大盟友。它允許您定義特定的PCW測量，並按需或特定時間表收集它們（您可以在文件或線上中閱讀這一功能）。事實上，資料收集器集甚至允許您收集ETW測量值，或PCW和ETW的組合。請注意，生成的ETL跟蹤在效能分析中不如WPR捕獲的跟蹤有用，因為它們缺少了許多關鍵的元資料。因此，在本書中，我們將重點討論使用WPR捕獲的跟蹤。

注意：資料收集器集也可以使用LogMan.exe內建程式從命令列管理，以及使用Performance Logs And Alerts：效能日誌和告警(PLA)通過Win32 API以程式設計方式管理。

注意：收集BLG檔案的另一種快速方法是使用內建TypePerf程式。例如，要捕獲每個程序CPU使用率，我們可以使用以下命令：typeperf "\Process(*)\% Processor Time" -f BIN -o PerProcessCpuUsage.blg。好訊息是，使用TypePerf，您可以知道應該提升哪個程序的優先順序（即typeperf.exe程序本身）。

Performance Monitor還附帶了報告生成功能，如果您在建立新的使用者定義的資料收集器集時使用預設建議模板，您就可以獲得這些功能。或者，您也可以只使用效能監視器附帶的系統\系統性能資料收集器集。

注意：內建資料收集器集配置為僅捕獲60秒的測量

雖然這些功能在穩態負載下對伺服器系統進行容量測量非常有用，但這些報告通常不包含對效能問題執行有效根本原因分析所需的資料。

使用正確的工具進行工作

正如我們在上一節中所看到的，我們嘗試過的用於診斷CPU飽和的每一個工具都有其缺點，工作管理員要求我們實時捕獲問題。資源監視器確實給了我們一分鐘的視窗，這要歸功於它的尾隨平均值，但沒有提供離線分析功能。接下來，我們查看了效能監視器，如果使用正確，它允許我們使用BLG檔案進行離線分析，這些檔案確實指向消耗系統上大部分CPU的程序。正如我們所看到的，對於某些型別的效能問題，PCW可以成為根本原因分析的有效工具。話雖如此，它的有效性受到各種限制，我們稍後會繼續討論。

注意：我們所回顧的內容提供了一個相當完整的內建工具清單，以及大多數Windows套件中包含的推薦工具。與大多數工具生態系統一樣，您還可以使用其他效能工具。其中一組值得明確呼叫的工具是SysInternal工具。在這個工具包中，您可以找到一個非常強大的工具，稱為Process Explorer，提供了工作管理員和資源監視器提供的大部分功能，而且還有許多改進。有關更多詳細資訊，請訪問http://www.sysinternals.com

回到第1章，在練習1.1中，我們已經看到了如何在WPR和WPA的幫助下使用ETW技術診斷相同的問題。PCW和ETW兩種不同的技術，都支援使用效能跟蹤（BLG for PCW,ETL for ETW）的離線分析，我們應該什麼時候使用哪種技術？讓我們在下一節中探討這些測量和分析平臺的利弊

PCW vs. ETW

回顧第1章，Windows中有兩個可用於收集效能測量的替代平臺：Windows效能計數器(PCW)和Windows事件跟蹤（ETW）。

效能計數器使您能夠取樣反映系統當前狀態的各種資料點。通過定期查詢這樣的計數器，您可以獲得系統狀態隨時間變化的檢視。例如，執行程序數的計數器將反映查詢計數器時正在執行的程序數。如果您每隔一秒鐘查詢此計數器，您可以繪製一個趨勢線圖，以顯示系統上執行的程序數隨時間的變化趨勢。

與效能計數器不同，效能計數器只能包含定期取樣的數字資料，ETW事件由事件提供程式（Event Providers）（負責記錄ETW事件的邏輯實體）在特定操作或狀態轉換髮生時的確切時刻進行記錄，並且包含豐富的資料。支援廣泛的資料型別，包括字串、結構化資料集、時間戳、GUID等。也與只能取樣的計數器不同，ETW跟蹤事件可以在狀態更改發生時進行記錄（即它們遵循推送模型（push model））。回到我們之前的監控系統上執行程序數量的示例，使用ETW的話，每次建立或終止程序時，您都會收到事件。從這些資料中，人們不僅可以獲得在任何給定時間點在系統上執行的程序數量，而且還可以訪問更豐富的資訊，包括程序名稱、確切的建立和終止時間戳、相應的命令列等等。

上面列出的兩種機制是在Windows上收集效能資訊的標準方法。它們都附帶了對應的一組豐富的日誌記錄和處理的API，以及一組匹配的命令列和基於UI的工具，用於收集和分析資料。

PCW早在ETW之前就出現了（早在Windows 95之前）。它的主要目的是支援從Windows中的系統元件按需收集效能指標。為了處理大量資料，在記憶體稀缺、磁碟速度慢的時代，每次感興趣的指標在更改其值時記錄事件是不可行的。因此，這些度量將由其自己的元件聚合，通常以自定義的方式聚合。這為那個時代創造了一個足夠好的監控平臺，且該平臺至今仍在使用——這主要是由於生態系統中眾多產品對效能計數器的大量投資。

ETW是在Windows效能團隊中Windows 2000建立的，但直到在Windows Vista釋出後，針對瞭解和優化windows效能才有了很大的推動力，此時ETW才全面發揮了作用。它提供了對系統活動的更深入的檢視，包括單個操作的級別，以及啟動這些操作的程式碼。

從Windows 7開始，許多系統元件開始切換到ETW進行根因分析。在許多情況下，這提供了一定程度的維測功能，而以前，如果不首先重現問題，肯定無法定位到根因。讓我們通過檢查這兩個平臺之間的主要差異來回顧是什麼讓他們實現了飛躍。

下表展示了程式碼開發方面的對比。

下表展示了根因分析對比

關於資料收集

關於效能分析

關於工具

表2.1至表2.4中列出的ETW的優勢包括能夠專注於亞秒級活動，以高精度將它們放置在時間軸上，以及能夠獲取呼叫堆疊和捕獲非數字資料型別。這些優勢使ETW成為典型效能問題根因分析的首選。

另一個值得記住的好處是，ETW基於事件的推送模型提供了更靈活的日誌記錄方法。您可以始終改進離線分析功能，但一旦提供了效能計數器，那就是你在該版本中獲得的所有。例如，內建效能計數器可能為給定度量值提供最小值、平均值和最大值，但它可能缺少90%分位數。如果你決定在程式碼成熟時關心95%和99%的百分位呢？更別提PCW將提供的任何統計資訊都硬編碼到特定的時間間隔。為了在分析中獲得真正的靈活性，我們顯然需要將資料聚合推遲到實際分析，而不是嘗試預測我們在執行時需要什麼資料。

這並不是說PCW應該被忽視。雖然缺乏一些列出的領域，但它仍然提供了足夠的價值，使我們在效能工程方面獲益。由於本書的重點是診斷，因此對PCW技術的詳細描述不在本書的範圍之內。不過，我們將在整本書中酌情提到PCW，以適用於其優勢可以有效應用的場景。

注意：請記住，效能工程可以側重於提高響應性和/或效率。考慮以下示例，其中PCW和ETW用於實現這些目標：

互動響應能力

測量時彙總：PCW –例如最小、最大和平均響應延遲

• 不變的
• 沒有好的工具支撐
• 可以監控資源使用情況的近似值，但無法與使用者互動關聯

分析時彙總： ETW -例如每個互動的開始/停止事件

• 靈活的
• 工具化（屬性）使用者互動可以與資源使用相關

效率： 資源使用率

測量時彙總： PCW --例如處理器用途、磁碟時間

• 好工具

• 遠端收集

• 告警

• DBMS整合

• 大時間跨度

• 缺乏呼叫堆疊可見性，無法將資源使用情況與相應的消費者和活動聯絡起來

分析時彙總： ETW--例如磁碟IO的啟停，上下文切換、CPU取樣事件

• 用於本地捕獲和分析的優秀工具
• 不太使用遠端收集
• 能夠使用呼叫堆疊識別負責特定資源使用的使用者和活動

PCW和ETW的互補優勢使它們成為兩種共生型別的效能反饋系統的良好候選者，我們將在下一節中回顧這些系統。

監控 vs 診斷（Monitoring vs. Diagnostics）

在大多數對跟蹤和提高產品效能感興趣的組織中，出現了兩個互補的流程：

監控--持續（即7*24小時）跟蹤關鍵業績指標，目標是：

• 確保監測指標達到和/或超過目標響應性、流動性和/或效率目標（效能目標）

• 在適當的優先順序和嚴重程度上出現目標違反和迴歸事件

診斷--按需（例如及時、基於觸發、基於升級等）對關鍵系統和使用者活動進行測量，目標是對通過監控出現的問題進行根本原因分析。

監控通常涉及跟蹤較長的時間段（跨越小時的時間段）。監控通常側重於低頻活動（例如1Hz以下），持續時間為一分鐘或更長。示例包括

• 聚合吞吐量（例如每分鐘平均/峰值操作）

• 每分鐘平均使用率（例如CPU使用率、磁碟使用率）

收集的資料通常足夠小，可以以業務可接受的成本保留數週甚至數月的資料，從而瞭解質量從一天到一天、一週到一週、月到月、釋出到釋出的趨勢。

另一方面，當問題浮出水面時，診斷就會發揮作用——通常是一個需要快速有效補救的高概率問題。這些問題可以通過測試（合成工作負載）或監控（遙測）主動地浮出水面，甚至可以由終端使用者被動地浮出水面。考慮到診斷大多數效能問題需要大量資料，因此需要收集更多資料才能成功進行根本原因分析。

為診斷收集的資料通常跨越幾分鐘，在此期間跟蹤高頻活動（遠高於1KHz）。此類活動通常具有亞秒級的持續時間（例如，單個磁碟I/O）。鑑於收集的測量結果的豐富性，由此產生的資料量可能是巨大的。因此，長時間保留它們可能相當昂貴，需要實施謹慎的保留策略，以避免不必要的資源浪費

注意：限制診斷測量期間收集的資料量的一個常見緩解措施是依賴迴圈日誌記錄技術，在這種技術中，特定大小的緩衝區以迴圈方式預先分配和覆蓋。這樣，僅保留最新的測量值（未覆蓋）。

注意：在評估監控和診斷反饋系統的效率時，有幾個關鍵指標。具體來說，檢測時間（time to detection，簡稱TTD）是有效監控的關鍵指標，而導致時間（time to cause,簡稱TTC）和補救時間（time to remediation, 簡稱TTR）是有效診斷的關鍵指標。這兩個反饋系統的一個共同指標是緩解時間(time to mitigation, 簡稱TTM)。典型的時間線是TTD→TTC→TTM→TTR，即您檢測到，然後是根本原因，然後是緩解，然後是根因（譯者注：這裡應該是補救吧？）。請注意，有些問題可以在沒有根本原因的情況下緩解，但要補救問題，您必須首先確定根本原因。

我們已經提到，監控通常是通過PCW實施的。這是否意味著ETW做了一個糟糕的平臺來實現監控？一點也不。您可以使用PCW構建的任何反饋系統也可以構建在ETW之上（請注意，情況並非如此）。事實上，ETW的結果可能會更有效。不過，PCW更早出現，在PCW之上構建的所有眾多效能監控工具也是如此，包括與資料庫的整合，這些工具提供了在監控領域的豐富的商業智慧可能性——尤其是在伺服器端。有許多效能指標可以通過PCW有效監控，並提供足夠的工具支援。

然而，在這本書中，我們主要關注有效診斷的方法論，只是順便提到監控反饋系統。在效能領域，市場上存在多種監控方法。討論這些問題超出了本書的範圍。

資料收集方法

收集效能資料有一些補充辦法。讓我們在本節中回顧一下它們。

資料發現和彙總方式

正如我們剛才在PCW與ETW的討論中看到的，從概念上講，收集效能資料有兩種方法。具體來說，資料收集可以遵循拉式模型，也可以遵循推式模型。在拉取模型中，資料會定期查詢，而在推送模型中，每次發生狀態轉換時都會記錄資料。收集的資料可以是瞬時的（例如當前溫度），也可以是累積的（例如整個拖後時間段的平均溫度）。

注：表2.5說明了推拉資料收集模型的幾個示例，描述了當與表示時間點的即時值或在時間間隔內聚合的累積測量一起使用時的場景：

推拉模式都有其優缺點。類似地，瞬時值和累積值在實際效能工程應用中都有用途

抽樣與歸因

在效能分析的上下文中檢視拉式和推式模型的另一種有趣的方法是考慮效能資料是如何生成的。存在兩種主要方法：

• 取樣（Sampling）是週期性或偶發狀態集合，後來被用於通過近似統計來度量活動

• 歸因(Attribution)是通過精確的事件劃定特定的活動，後來被用於精確統計確切發生的事件來度量活動

譯者注： 沒咋看懂

請注意，取樣是拉取模型的示例（資料在取樣發生時拉取），而歸因是推取模型的示例（資料在事件發生時推出）。

把這些新術語應用到PCW和ETW的角度來看的話，PCW資料在完全由消費者定義的時間表上通過輪詢進行取樣得到，PCW的資料匯聚在生產者端，它低頻監控使用者定義的資料。相反，ETW資料通過生產者在事件發生時推送事件得到，資料的聚合在消費者這端，ETW提供對診斷中通常必要的高頻資料的訪問（歸因）。

定期提取資料的行為通常被稱為輪詢。正如我們將在第7章中看到的，基於輪詢的效能資料收集的一個示例是基於樣本的CPU分析，其中CPU使用情況（預設情況下）每毫秒取樣一次。

注意：具體來說，CPU取樣分析的工作原理是定期查詢處理器指令指標位置並將其映射回程式碼。使用這些取樣資料，人們可以重新建立一個相當準確的圖片，說明在程式中的時間花費。

取樣的一個顯著優點是，它不需要對正在執行的程式程式碼進行任何修改，而且通常不會過於侵入性。與取樣不同，歸因需要修改程式碼，並涉及重新啟動正在診斷的程式。

注意：程式中的自定義活動的歸因需要對相應的程式進行更改。作業系統活動（如上下文切換和磁碟I/O）的歸屬可在任何時間點按需提供，因為這些活動已經在Windows中進行了檢測

歸因的一個顯著優點是它提供了高精度的測量。另一方面，通過抽樣獲得的資料本質上是不顯眼的，它可能會忽略其兩個相鄰樣本之間發生的活動。另一方面，歸因只捕獲狀態轉換，並且可能會錯過在這些轉換之間發生的活動，而取樣通常仍然可以獲得足夠好的近似值。我們將在第7章中使用CPU作為案例研究，對比這兩種互補的測量方法。

請注意，歸因可能會導致生成比取樣更多的效能資料。在抽樣的情況下，資料量與抽樣率成正比，而在歸因的情況下，資料量與歸屬活動的數量成正比。

關鍵點回顧（Key takeaways）

來回顧下我們迄今所學到的內容，Windows提供了幾種用於效能監視和診斷的內建工具：工作管理員、資源監視器和效能監視器。對於CPU佔用率分析來講：

工作管理員

• 幫助清點正在執行的程式，並識別那些消耗大量系統資源的程式
• 不提供記錄和離線分析功能，使其用途僅限於幫助識別持續的飽和問題

資源監視器

• 記錄過去60秒的資源活動

• 與工作管理員類似，不提供記錄工具和離線分析功能，使其用途僅限於幫助在執行的最後一分鐘內識別持續的飽和問題

• 比工作管理員提供更多的系統活動可視性

效能監視器

• 與工作管理員和資源監視器不同，支援通過使用使用者定義的資料收集器集捕獲的BLG檔案進行離線分析

• 允許在離線分析中跟蹤新啟動的程序

• 在近乎實時的視覺化分析中，僅顯示在PerfMon之前啟動的程序的活動

Windows提供了兩個用於記錄和收集效能資料的互補基礎設施：PCW和ETW。這兩個平臺已經發展到分別涵蓋監控和診斷反饋系統。

PCW

• 完全由消費者定義策略，通過輪詢進行資料取樣
• 提供對在生產者一側聚合的低頻資料的監控訪問
• PerfMon是最常見的Windows工具，用於收集PCW資料以及線上和離線視覺化
• 通過BLG檔案啟用PCW離線分析

ETW

• 資料由生產者在事件發生時推送，所有聚合都發生在消費者側
• 提供對診斷中經常需要的高頻資料的訪問
• WPR是收集ETW效能跟蹤的首選工具，而WPA是基於ETW的進行效能診斷分析的優秀工具
• 通過ETL檔案啟動ETW離線分析

這兩個平臺都可以有效地分析某些型別的效能問題的根本原因，但ETW在大多數情況下在診斷方面佔上風。PCW在大多數監測情況下仍然可以非常有效。
由於這本書主要涉及教您如何診斷效能問題，我們將把大部分注意力都花在ETW上。正如我們提到的，ETW比PCW提供了更多的分析靈活性，特別是當您需要對收集的資料執行非平凡分析時。在下一章中，我們將向您展示如何在Windows上使用WPR進行基於ETW的效能測量。