【Fundamentals of Windows Performance Analysis】翻譯，第四章： 基本定界

在第2章中，我們介紹了一些可以用來監視和/或分析系統性能的内置工具。 我們還回顧了Windows的性能計數器(PCW)和Windows的事件跟蹤(ETW)之間的差別，并學習了如何使用這兩種技術收集性能日志(即Trace)。 最後，我們得出結論，ETW更适合于定位複雜的性能問題，而PCW在監控長時間活動方面更有價值。 然後在第三章中，我們展示了如何使用WPR收集ETW性能日志。

在本章中，我們将繼續建構我們的ETW處理技能集。 我們将從學習如何在資料的海洋中定位。這是他們通常帶來的。 回想一下，ETW性能跟蹤本質上是各種系統和第三方元件記錄的帶有時間戳的事件的集合。 WPA幫助拼湊所有這些資料，并在時間軸上友善地可視化它。 正如您将看到的，知道要關注時間軸的哪個時間範圍對于從根本上造成性能問題是至關重要的。 我們将把這些時間範圍稱為感興趣的區域，并通過一系列互相建構的簡單示例展示，識别這些區域如何有助于發現它們内部的性能問題和根本原因

感興趣的區域可以表示系統活動(例如程序生命周期)、使用者活動(例如焦點中的視窗)或應用程式活動(例如函數調用)。 此外，不管使用者是什麼，感興趣的區域也可以表示資源使用情況(例如，高磁盤使用vs.低磁盤使用區域)。

那麼這些感興趣的區域從何而來? 其中一些來自現有的系統範圍的ETW檢測，如表示GUI延遲的标記、程序生命周期、焦點視窗、二進制檔案加載等。 其他的可以由單個系統元件(如處理器功率管理器(PPM)或服務控制管理器(SCM))記錄的ETW事件構造。 還有一些可以由使用者應用程式(如Internet Explorer和Media Player)記錄的事件形成。 事實上，正如您将在本書後面看到的，任何應用程式(包括您的應用程式)都可以記錄ETW事件。 我們将用一對啟動/停止事件顯式劃分的感興趣區域稱為感興趣的屬性區域。

不是所有感興趣的區域都明确地受到ETW事件的限制——有些對應于資源使用率高或低的區域，或者是已知的“感興趣”事件或模式的鄰近區域。 如果在這一點上，這些示例聽起來與實際情況脫節——請不要擔心——在本章中，我們将引導您通過實踐練習，示範如何在定位性能問題的時候使用顯式和隐式感興趣的區域

感興趣的屬性系統活動區域

正如我們所提到的，Windows自帶的檢測工具可以幫助識别許多感興趣的基本區域，這些區域可以作為終端使用者活動的良好代理。 這些區域包括表示程序生存期、UIdelay和焦點視窗的時間間隔。 通常，我們感興趣的是關注這些區域的子集，因為它們與問題中的使用者場景很好地對齊。 下面的練習将示範如何識别這些基本系統概念感興趣的區域。 在開始練習之前，讓我們首先快速回顧一下這些概念，以及它們對性能分析的重要性。 如果你已經熟悉這些概念，可以直接跳過這個練習。

程序

在計算機發展的早期，計算機一次隻執行一項任務。 多個任務被分批處理并按順序執行。 在不同的任務之間共享計算機時間的需求催生了如Windows的多任務作業系統。 這裡出現了兩種形式：協作式多任務排程模型和搶占式多任務排程模型

在協作模型中，每個任務都應該是一個好公民，并在合理的時間内将CPU時間留給其他任務。 “合理”的定義則留給系統使用者(例如應用程式)。 很容易看出這個模型在性能上是如何崩潰的。 相反，在搶占模型中，作業系統充當仲裁人，決定哪個任務在哪個CPU上運作以及運作多長時間，可能在其他任務執行過程中搶占它們。 使用此模型，單個應用程式接管整個系統變得更加困難。

随着任務複雜性的增加，需要将它們進一步分解成子任務。 這些子任務本質上每個子任務都表示一個執行流，所有子任務都托管在一個父容器任務中。 在主流作業系統中，程序作為父任務的容器，線程作為子任務的容器。

使用這個術語，當使用者希望通過啟動應用程式來執行給定的任務時，作業系統會建立一個程序，在該程序中建立一個線程(然後可以建立更多線程)來執行該應用程式的代碼。 每個程序都由一個惟一辨別符辨別，通常稱為PID(程序ID)。 這個ID是在程序建立時配置設定的，并在其整個生命周期中持續存在。

注意:PID可以被新建立的程序重新使用——這就是為什麼通常需要PID和程序建立時間的組合來唯一辨別一個程序。

正如我們将在下面的練習中看到的，Windows自帶一個ETW Provider，它提供了一種簡單的方法來收集關于哪個程序在什麼時間運作的資訊。 更好的是，WPA還提供了易于使用的圖表，幫助您可視化這些資訊。 在本書的後面，我們将帶您通過類似的步驟來檢視線程生命周期資訊。

視窗焦點

正如我們提到的，Windows是一個多任務作業系統。 簡而言之，這意味着許多程序同時執行，并發地共享系統硬體和軟體資源。 然而，對于人類來說，往往很難同時專注于許多事情，是以我們傾向于專注于手頭的一項任務。 是以，當與計算機互動時，使用者在任何時間點通常與單個應用程式互動，或者更确切地說，與該應用程式中的單個視窗互動。

在出現性能問題時，知道哪個應用程式視窗處于焦點位置，并計算出導緻問題的使用者互動視窗的确切順序，對于報告的問題的根源來說是非常有益的，有時是至關重要的。 即使使用者提供了問題的描述，這種描述也隻是一種感覺，而感覺可能是不準确的。 例如，使用者可能會忽略他們曾經切換到不同的應用程式這一事實。 如果該應用程式為了顯示其内容而需要執行一些工作，那麼這可能會導緻問題。

您可能還需要知道哪個視窗在什麼時間處于焦點中，以便确定給定的UI延遲是否導緻了使用者可感覺的問題。 當使用者描述問題時，這些小細節往往會被遺忘和/或省略，尤其是當他們對自己的電腦問題感到情緒激動時(而且大多數人确實如此)。

為了幫助解決這個問題，我們将在下面的練習中看到，Windows有一個ETW提供程式，它提供了一種簡單的方法來收集在什麼時間哪個視窗處于焦點中。

UI延遲（UI delays）

當應用程式的UI或系統本身出現明顯的延遲時，使用者通常會抱怨性能。 事實上，這些延遲在某些應用程式中非常常見，從Vista釋出開始，Windows就将處理超過500ms的Windows消息的延遲視為“無響應”，并将内容停止更新的視窗幽靈化，如圖4.1所示。

注意:對于幽靈視窗，桌面視窗管理器還會在視窗标題中添加“(未響應)”，以更清楚地表明應用程式UI未響應，無法互動。

注意:正如我們在本書後面會看到的，任何超過500ms的延遲都被認為是不可接受的，使用者互動應該讓使用者感到及時響應

應用程式的響應性是通過其處理視窗消息的延遲來度量的。 因為所有的Windows GUI應用程式都有一個循環來處理視窗消息，比如輸入和繪制，是以将應用程式的響應性與操作的這一關鍵部分綁定是合理的。 這個循環通常被稱為消息泵。 可見前景視窗的消息進行中的任何延遲，都不可避免地直接轉換為該視窗的使用者感覺到的延遲。

注意: 幽靈視窗機制要歸功于windows vista引入了桌面視窗管理器（dwm）。這樣即使一個視窗未響應，作業系統還是可以繼續在桌面上顯示其他内容(這個将在第6章詳述)。Vista之前, 應用程式習慣于将其視窗内容直接呈現到螢幕上，是以Windows無法輕松地增強使用者對應用程式視窗的體驗 。

注意：應用程式視窗幽靈化并不一定意味着應用程式本身hung死。 通常情況下，如果您等待的時間足夠長，它的UI将再次響應。 然而，這樣的體驗會讓使用者非常沮喪，是以無論如何都要避免。 如果您正在分析使用者面臨的性能問題，那麼很可能會看到UI延遲。 如果您在應用程式中發現它們，請修複它們。 我們在這裡能給出的最好的通用建議是，在GUI線程中隻保留對ui至關重要的工作。 将所有其他密集型活動放到其他線程。

注意:知道什麼要在UI線程上保留，什麼要解除安裝是一個平衡練習，這并不總是微不足道的。 請記住，将一些操作解除安裝到另一個線程實際上可能比在原始處理線程上快速處理它們代價更高。

現在我們已經了解了最重要的系統活動，接下來讓我們快速回顧一下如何選擇WPA中感興趣的區域。 有關更深入的詳細介紹，請參閱附錄A。

選擇感興趣的區域 (Selecting regions of interest in WPA )

有兩種方法選擇感興趣的區域，典型的：

• 時間序列選擇
• 資料序列選擇

使用時間範圍選擇，可以在圖上拖動選擇，定義感興趣的連續區域。 典型的應用包括基于視覺線索從a點到B點選擇一個區域。 這些線索可能來自顯式記錄的事件，也可能來自識别可視化資料系列中的特定模式。 在後面的練習中，我們将看到多個這樣選擇的示例。

對于資料系列選擇，隻需單擊圖例控件或表中的給定元素(也可以進行多選)。 正如我們将看到的，WPA随後還根據底層資料為各自感興趣的區域生成選擇 。

注意:從資料系列選擇中建立的感興趣區域可以使用屬性資料或抽樣資料形成。 在屬性的情況下，将記錄不同的事件，以表示區域的确切邊界。 在抽樣的情況下，收集多個資料樣本，然後基于一個斷言評估，以确定它們是否對感興趣的區域有貢獻。 在下面的練習中，我們将看到有關屬性區域(例如UI延遲)和采樣區域(例如采樣CPU使用率)的例子。 要了解更多細節，請參閱第二章的“抽樣vs.歸因”章節。 在第7章、第8章和第9章讨論處理器性能分析時，我們還将更仔細地研究這兩種度量方法之間的實際差異，這兩種方法都大量使用。

練習4.1:在典型的性能跟蹤中識别感興趣的基本區域

在這個練習中，我們将看到如何在典型的性能跟蹤中識别感興趣的區域，您将在本書中反複應用這項技能。 這也是在現實世界中練習性能分析時首先要做的事情之一。 具體來說，我們将檢查當我們在記事本中打開一個非常大的檔案時發生了什麼，因為它變得無響應 。

正如本書其餘部分所述，我們将使用免費的WPR和WPA ETW工具進行調查。 與具有簡單的跟蹤捕獲UI的WPR不同，WPA是一個複雜的工具。 為了幫助您輕松地使用它，本書通過貫穿全書的練習逐漸介紹了它的大部分功能。 附錄A是對WPA的系統概述，包括全書中提到的内容以及我們在練習中沒有強調的功能。

概述

這個示例使用名為fsutil的系統實用工具建立了一個500MB的data.txt檔案。 然後使用記事本打開該檔案，導緻記事本在打開這個大檔案時失去響應。

問題表現

正如我們看到的，當打開一個非常大的檔案時，記事本變得沒有響應。 正如我們前面提到的，每當應用程式變得無響應時，Windows就會隐藏其視窗并将(無響應)添加到其标題中，如圖4所示。

無響應的應用程式通常是性能問題的一個很好的訓示器。

注意:當應用程式變得永久無響應時，通常意味着它是一個死鎖問題，這更偏向功能問題，而不是性能問題。 另一方面，臨時無響應的應用程式顯然更偏向于屬于性能問題。

分析方法

這本書有預先抓取好的log，是以你不必花時間為這個和其他練習捕獲log。 然而，為這個練習捕獲您自己的trace還是非常有價值的 。因為它将幫助您建立對端到端性能分析工作流的信心。 在我們完成這個練習的分析方法之後，我們将在另一個部分向您展示如何為這個場景捕獲您自己的trace（譯注：最新win10版本打開一個500M的大檔案已經不會出現未響應）。

本節描述如何在記事本中檢查和評估加載一個非常大的檔案。

1. 打開etl檔案
2. 雖然這不是你能看到的最大的trace，但它包含了很多活動，為了有效地分析它的内容，我們需要知道在哪裡集中我們的注意力。 WPA提供了許多不同的詳細圖表，您可以利用它們進行分析。 這些圖被組織成特定于它們所代表的資料的組。 這些組織包括:
   • 表示CPU活動的Computation圖
   • 表示在儲存設備上活動的Storage圖
   • 可以表示在任何時間點的記憶體使用的Memory圖
   • 可以幫助您了解在日志記錄區間發生了什麼網絡活動的Network圖
   • 顯示系統功耗情況的Power圖

​ 我們将在後面的練習中簡要地看一下這些圖表，并在本書後面的章節中花整章的時間讨論其中的一些組。

1. 還有一種特殊類别的圖稱為系統活動圖（System Activity），它包含幾個圖，告訴您在記錄跟蹤時系統上發生了哪些邏輯活動
2. WPA在一個實時縮略圖中組織所有可用的圖，為您提供完整圖的預覽。 這些頂級實時縮略圖也被稱為kpi或關鍵性能名額(Key Performance Indicators)，因為它們可以讓您快速了解資源使用情況，而無需檢視底層的詳細圖表。
3. 這些實時縮略圖可以幫助您選擇您想要檢視的圖表。 要通路這些圖，您可以使用Graph Explorer(預設情況下)停靠在WPA主視窗的左側。 讓我們首先通過展開System Activity組來仔細檢視圖，如圖4.3所示。

   

程序生命周期檢視

1. 在圖4.3中，我們可以看到許多可用的圖，每個圖都表示跟蹤中的一些有價值的資訊。 讓我們從檢視程序圖（Processes）開始。 為此，輕按兩下其預覽縮略圖或将其縮略圖拖動到右側的空白區域，正如我們在上一章中所說的，這被稱為分析視圖。 完成後，您将看到如圖4.4所示的視圖。

注意:人們常犯的一個錯誤是試圖拖動圖形的标題，這是在本書寫作時，沒有預期到的情況。

1. 在我們看這個圖表告訴我們什麼之前，讓我們先花一些時間來了解一個詳細的圖表是由什麼組成的。 圖4.5顯示了三個基本建構塊，它們構成了你将在WPA中看到的每個詳細圖表

   

2. 圖形資料視圖（Graphical data view），或者叫圖形(graph)，對應的可視化底層資料，顯示在表格資料視圖(Tabular data view)中，簡單成為表格（table）中。 當選擇一個區間範圍後，這兩個視圖是同步的。 資料通常以表中金線左側的一個或多個次元為中心，并在金線右側聚合。 例如，在圖4.5中，程序生命周期資料由生存期類型(暫時的（Transient）和永久的（Permanent)和程序名稱來決定。 圖4.5中的金線右側的資料對每一組進行了聚合，例如，暫時的程序的總持續時間Duration(s)Sum值是單個暫時的程序的所有持續時間之和。

   在接下來的章節中，我們将提供預置的彙總方法，但你也總是可以自己重新建立它們。 我們将在附錄A中更詳細地讨論WPA詳細圖的原理。

3. 請注意，您可以通過拖動分隔這些塊的邊界線來調整這些塊的大小，以顯示更多或更少的資料。 事實上，圖4.5中的legend控件在預設視圖中不夠大，無法向我們顯示所有的瞬态程序及其長名稱，是以讓我們調整它的大小，如圖4.6所示。 暫時的（Transient）程序是所有在收集日志期間啟動和/或退出的程序

   

   注意:圖中右側标題為Trace Rundown的灰色區域（圖形資料視圖的尾部的一個矩形區域）是ETW跟蹤會話停止的時間段。 如果會話正在記憶體中收集資料，那麼在此期間收集的所有資料都會被重新整理到磁盤。 由于刷盤是磁盤I/O和/或CPU密集型活動，是以會影響度量。 是以，在分析中最好忽略這一部分。 除了影響度量之外，這段時間WPR會逐個關閉啟用的ETW提供程式，是以不能保證您正在尋找的事件會出現在跟蹤的這一部分中 。
4. 這個圖告訴了我們什麼? 回想一下，在第2章中，當我們使用不同的工具來診斷CPU飽和導緻的系統減速時，我們檢視了系統上運作的所有程序。 這些工具中的每一個都以略微不同的方式表示流程資訊。 我們看到系統上有很多正在運作的程序，它們共同消耗了系統資源。 WPA也不例外，它為您提供了一個很好的視圖，讓您了解哪些程序在系統上運作。 事實上，您不僅看到了哪些程序存在，而且還看到了它們在您的記錄期間何時啟動和終止

注意:其中一些(瞬态)程序是在記錄期間建立和/或終止的，而其他(永久)程序則存在于整個跟蹤過程中。 Processes圖通過将它們分組向您展示了這兩種情況。 預設會聚焦在瞬态程序圖，因為通常瞬态記錄會更活躍。

1. 想一下我們為什麼要進行trace -- 當打開一個大檔案時記事本未響應。 要從根源上找出這個問題的原因，我們首先需要找到記事本在跟蹤中何時運作，而流程圖正是為此而設計的。 最簡單的方法是通過點選legend控件中的Notepad .exe條目選擇Notepad，如圖4.7所示。
2. 我們選擇的程序對應的投影現在出現在分析視圖底部的時間軸上。 它顯示了Notepad在記錄的trace中運作的确切時間。 您還可以清楚地看到在那段時間記憶體在的其他過程，正如我們稍後将看到的那樣，這些過程可能對記事本的執行産生了實質性的影響
3. trace的開始表示為時間0，然後所有其他活動的時間戳都與之相關

注意:在圖4.7中，您可能已經注意到Start時間戳不是精确的零，而是~0.0529s。 這是由于WPA将視圖的左側剪切到跟蹤中的第一個事件(在本例中是這樣)造成的 。既在跟蹤開始後的0.0529s的時候收到了第一個事件。 在使用循環緩沖區跟蹤時，您可能會更好地欣賞這個有用的特性，在循環緩沖區跟蹤中，記錄持續了數小時，但隻有最後幾分鐘的事件才能打到最終的Log裡面。

焦點視窗

1. 程序生命周期是否是用于辨別日志中感興趣的區域的良好度量? 這是一個很好的開始，但是請記住，應用程式不一定要在前台才能運作。 事實上，記事本可以隐藏在其他視窗後面，或者最小化，使用者隻在其生命周期的一小部分時間内與它進行互動。 顯然，如果我們看看Notepad在什麼時候在前台，我們可以做得更好。
2. 碰巧WPA有一個這樣的圖表，叫做焦點視窗圖（Window In Focus）。 您可以通過輕按兩下其預覽縮略圖或拖動它，将其添加到分析視圖，類似于Processes圖。 完成之後，您将看到如圖4.8所示的視圖。
3. 正如你所看到的，WPA要顯示的資料比螢幕上的空間多得多。 無論您的顯示器有多大，最終您都會遇到螢幕空間的限制。 幸運的是，就如何在螢幕上安排資料而言，WPA非常靈活。 目前我們并不太在意關于Processes圖中的表格資料視圖，是以讓我們通過單擊圖示折疊它(有關WPA圖管理的詳細資訊請參見附錄A)。

   

4. 新添加的圖展示了所有的時間點，分别是哪些應用程式處于焦點狀态。
5. 注意，我們首先與WPR GUI進行互動以開始錄制，然後切換到控制台(conhost.exe)來啟動我們的練習腳本。 腳本然後啟動Notepad (Notepad .exe)。

注意：Focus圖中的Window不會顯示無視窗的程序(例如指令行工具)。 是以，即使我們在啟動記事本之前運作兩個fsutil.exe程序執行個體來建立data.txt檔案，您也不會在這個圖中看到它們

1. 現在我們到了有趣的部分。 當記事本運作時，圖表顯示一個名為dwm.exe的程序将焦點從記事本上轉移開。 這個程序是什麼? 當記事本運作時，我們有沒有看到其他應用程式進入前台? 沒有，但我們确實看到窗戶被幽靈化了。
2. DWM代表桌面視窗管理器，它是Windows桌面表示子系統背後的組合引擎。 當有視窗的應用程式變得無響應時，DWM負責将自己的視窗放在無響應的應用程式視窗的頂部，以顯示該應用程式渲染的最後一張圖像的幽靈版本。 它還将(未響應)文本添加到視窗的标題中
3. 那麼，DWM在焦點上的時間是否代表Notepad沒有響應的時間區域呢? 嗯,有點。 DWM隻會在使用者試圖與之互動時把視窗幽靈化。 畢竟，除非它影響到使用者，否則揭示這個問題是沒有價值的。 那麼我們如何找到Notepad失去響應的時間區域 ？

UI delays

1. 為了檢視給定視窗應用程式何時沒有響應，WPA提供了UI Delays圖。 這個圖非常有用，事實上，每當日志中出現任何UI延遲時，都會将System Activity KPI圖放在圖組的頂部
2. 圖4.11顯示了我們将UI Delays圖添加到分析視圖中，并調整其他圖的大小，以幫助将所有三個詳細圖放入視圖中。 注意，為了适應螢幕截圖中的所有三個圖表，我們隐藏了前兩個圖表的表格
3. 當任何給定的視窗應用程式在一段特定的時間内沒有處理windows的消息時，就會被檢測到未響應，并記錄一個ETW事件。在本書的後面，我們将看到響應在可接受延遲方面的真正含義。 然後，WPA使用這些事件來繪制表示時間軸上相應延遲的區間。 當然，在與無響應UI相關的性能分析調查期間，這些間隔是感興趣的區域的主要候選區域 。
4. 你會注意到notepad.exe程序實際上是兩個元素的折疊組(在圖例和表中)。 您可以通過單擊notepad.exe左邊的圖示來展開它。 你會看到類似于圖4.12所示的内容，即你會發現兩個不同的延遲，即MsgCheck延遲和Input延遲

   

5. MsgCheck延遲表示視窗應用程式不處理傳入視窗消息的時間區間。 Input延遲表示使用者意識到應用程式沒有響應的實際時間，因為他/她試圖與應用程式的視窗互動,即此時開始在點選視窗
6. 這就是我們對WPA中三個主要的感興趣區域圖的回顧。 我們将使用這些圖來幫助找到感興趣的區域，以便在本書的軌迹中進行詳細的分析。

您将注意到前台和背景應用程式都記錄了UI延遲。 由于使用者關心的是這些視窗的響應性，是以一般來說，您應該關注前台應用程式中發生的延遲

注意:當捕捉包含在書中的痕迹時，在嘗試與記事本的視窗互動之前，我們已經等待了大約四秒鐘。 這與圖4.12中相對于MsgCheck延遲開始的Input延遲緊密對應，從圖中可以看到，MsgCheck延遲是在應用程式啟動時開始的。 如果您手動打開記事本，然後使用它的檔案|打開菜單選項打開大檔案，您将看到MsgCheck延遲在應用程式啟動後才開始。

自己嘗試複現一下上述問題

既然您已經使用我們包含的跟蹤完成了整個練習，我們建議您對自己的跟蹤重複這些相同的分析步驟，并觀察哪些問題再次發生，哪些問題沒有發生。 也可以在您自己的跟蹤中尋找其他問題

1. 打開WPR
2. 勾選 First Level Triage, 詳細級别選擇Verbose
3. 在Resource Analysis選項中，勾選Disk I/O Activity、File I/O activity、 Resident Set Analysis
4. 開始記錄
5. 管理者權限打開控制台
6. 運作如下腳本：

   REM create a new file
   fsutil file createnew data.txt 500000000
   
   REM set the valid data length
   fsutil file setvaliddata data.txt 500000000
   
   notepad data.txt
   del data.txt
              

7. 這個腳本建立了個500MB的檔案并打開它
8. 等幾秒鐘後點選記事本視窗，你将會發現它被幽靈化了
9. 當記事本再次可以響應的時候，關閉它，然後腳本最後會把臨時建立的大檔案删除掉。
10. 儲存這份WPR日志。

現在，你可以嘗試用同樣的分析步驟來再次定位下這個問題。

關鍵點

現在我們回顧一下至今為止所學：

• 想要定位性能日志的根因，當務之急是找到看哪個區域，既識别關鍵區域。
• 左側羅列各項概要資訊，可以從中選擇自己需要的
• WPA中的Graph Explorer按關鍵區域将可用的詳細圖組織成邏輯組，每個組由關鍵性能名額(KPI)圖表示 。
• System Activity組提供了對幾個關鍵區域的入口，包括焦點視窗、程序生存期和UIdelay
• WPA支援顯示僅圖形、僅表格、圖形表格混合視圖
• 可以将多個WPA圖添加到同一個分析視圖中，所有圖都共享相同的時間軸