|
Self |
A graphical representation of the Self (%) 列的一個圖形表示。更寬、更紅的條塊表示更熱的方法。 |
|
Tree (%) |
特定方法在調用堆棧中任何地方時採用的抽樣百分比。此值表示處理此方法和它調用方法（子孫）的時間百分比。此值很好地指出了您應用程序中花費了最多處理時間的區域。 |
|
Tree |
Tree (%) 列的一個圖形表示。更寬、更紅的條塊表示更熱的方法堆棧。 |
|
Samples |
在堆棧頂部運行特定方法時採用的抽樣數量。 |
|
Method |
該方法的完全限定的表示，包括了包名稱、類名稱、方法名稱、參數和返回類型。 |
單擊列標題，按升序或降序對所有這些列排序。理解這一點後，您可深入分析工作負載的性能特徵。導航此表的一些有用技巧包括：
• 單擊表中的一行將顯示底部面板中顯示執行該方法的完整調用路徑。
• 在探查有效期間執行該方法時，將顯示
Timeline
選項卡。這可能很有用，您無需關注配置文件中在之前（或許在升溫期間）執行的某項功能，然後離開。
• Filter methods
文本框對搜索特定類和過濾配置文件的剩餘部分很有用。這僅應用於下鑽您應用程序的詳細信息，以刪除所有其他非應用程序類。作為一個示例，圖 15 顯示了按 “daytrader” 過濾的配置文件，因為所有 DayTrader 應用程序類的包名稱中都包含 “daytrader”。這使您能夠集中精力查找應用程序中使用資源最多的方法。
圖 15. DayTrader 過濾的 Method Profile 視圖
如果應用程序有一個特定的方法使用了大量 CPU 周期，然後 Health Center 將它標記為 Analysis and Recommendations 面板中一個不錯的優化候選者。一個示例如圖 16 所示。
圖 16. 優化候選者示例
可花幾天時間分析 Method Profiling 視圖，以查找一個應用程序的性能改進。因為輸出可保存到一個文件中，所以對比應用程序更改非常簡單。應用程序開發人員可執行一項通過 Health Center 掛鈎來部署和執行負載測試的更改，並且您可對比以前的配置文件信息，查看開發人員更改的方法增加還是降低了處理需求。
鎖定分析
多線程應用程序需要同步（或鎖定）共享資源，以使資源的狀態保持一致。這種一致性可確保在一個線程讀取另一個線程時，該線程的狀態不會更改。
當在具有大量處理器的系統上部署的高負載應用程序中使用鎖時，鎖定操作可預防應用程序使用所有可用的處理資源。想像一下一個在 8 核機器上運行的應用程序，它的主要應用程序代碼路徑高度同步，所以一次只能執行一個線程。這可能使其他 7 個線程處於等待狀態。
當在大型的多核（4 個以上）機器上運行時，鎖分析對確保應用程序可擴展並利用所有可用的硬件資源至關重要。（如果應用程序在單核機器上運行，這裡的分析可能沒有太大價值。）Locking 透視圖分析鎖的使用，幫助識別應用程序或 Java 運行中阻止應用程序擴展的爭用點。單擊 Locking 鏈接後，應會顯示一個類似於圖 17 的面板。
圖 17. Health Center – Locking 視圖
初看起來，Moniors 視圖可能很難使用和理解。但是，Health Center 文檔詳細描述了這個面板，以幫助您理解這些指標。表 2 描述了該表中的列的內容。
表 2. 監視器
|
列 |
描述 |
|
% miss |
總 Get 或獲取次數的一個百分比，對於這部分 Get 或獲取，嘗試在同步的代碼上獲取該鎖的線程在獲取鎖之前必須阻塞。 |
|
Gets： |
在充實期間，獲取該鎖的總次數。 |
|
Slow： |
由於一個鎖已被另一個線程擁有，請求線程必須為其等待鎖的非遞歸鎖獲取的總次數。 |
|
Recursive： |
遞歸獲取的總次數。當請求線程已擁有監視器時，就會發生遞歸獲取。 |
|
% util： |
持有該鎖的時間量除以接管輸出的時間量。 |
|
Average hold time： |
一個線程持有或擁有該鎖的平均時間量。例如，同步的鎖中花費的時間量（以處理器時鐘單位計算）。 |
|
Name： |
監視器名稱。如果不知道名稱，則此列為空。 |
該表列出了被充實的每個 Java 監視器。% miss 列是最初的關注點。高 % miss 表明受鎖保護的同步化資源上發生了頻繁的爭用。這種爭用可能阻止 Java 應用程序進一步擴展。
如果一個鎖具有一個較高的 % miss 值，請查看 Average hold time 和 % util。一些技巧如下：
• 如果 % util 和 Average hold time 都很高，您可能需要減少在持有鎖期間執行的工作量。
• 如果 % util 很高，但 Average hold time 很低，您可能需要使受鎖保護的資源更加細粒度地將該鎖分離為多個鎖。
結束語
沒有正確的工具和知識，開始執行性能測試和分析最初可能會很難。但是，本文表明，用戶可以執行一些較簡單的步驟來確保執行正確的性能測試，並確保應用程序瓶頸已消除，從而儘可能高效地執行應用程序。
即使 DayTrader 可能與您的應用程序不同，但本文中描述的測試性能和識別瓶頸的方法所發揮的作用是相同的。對較慢時期的小用戶負載一直到峰值使用時期的高用戶負載執行測試，這對理解您應用程序的特徵至關重要。記錄一些關鍵指標，用它們來對比應用程序或環境更改，這對理解性能降級的可能根源至關重要。最後，IBM Health Center 工具通過垃圾收集、方法探查和鎖探查視圖簡化了性能分析，幫助您確保儘可能高效地執行應用程序。
以下文章點擊率最高
Loading…