Neo's Life

星期一, 11月 06, 2006

Java Profiler - YourKit Java Profiler(二)

Telemetry


當我們開起YourKit 並且連線到要監控與Profiling 的Java Application 後,第一個看到的頁面就是Telemetry 的頁面。頁面中可以看到一些On-line 的數據,其中包含有:CPU & Memory、Garbage Collection、Classes、Threads、Summary。暫且先不管這些數據的用途、與意義,YourKit 會在AP 一起動就開始記錄這些Telemetry。只要AP 不停,一旦YourKit 連上該AP,這些數據都會完整的被呈現在YourKit中。這是一的不錯的優點,因為有些Profiler 並沒有做到這個功能。而這對我們保存完整的Telemetry 以供爾後分析是很重要的。不過,就如同之前所說的,我們只能用YourKit 手動的來保存Telemetry。並沒有辦法用Off-line 的方式來保存這是很可惜的地方。下圖為Telemetry 的頁面:



在上圖中我們可以看到兩個主要的資訊:CPU utilization 與Memory usage。一般來說,大多的Profiler 比較少提供CPU 的使用率,不過YourKit 倒是有提供。CPU 使用率對我們而言有什麼重要的意義呢?在Wait-based tuning approach 中,CPU utilization 是一個相當重要的指標,特別是在調整Thread Pool 的時候。一般建議,CPU utilization 在正常使用情況下,最好是保持在80-85% 左右。透過觀察CPU utilization 與Thread Pool utilization 以便調整 Pool size,使CPU utilization 能夠達到較佳的狀態,提升整體性能。

在Memory Usage 的部分,YourKit 提供了Heap 與Non-Heap Memory 的相關資料。Memory 相關的圖表能夠顯示記憶體隨著時間被使用的狀況。大約是JDK 1.2 以後,Sun 提出了Generation garbage collection 的概念。Heap Memory 大略被分成Young Generation 與Old Generation,越老的Java Object會被劃分到Old Generation 中。一般來說,檢查有沒有Memory leaks 最有效的方法就是監控Old Generation 的Memory usage 趨勢。但是在YourKit 並沒有根據Generation 來分開統計,有點遺憾。當然這是不是為了要考量到不同的JVM implementation 而所妥協出來的功能就不得而知,因為每個非Sun 的JVM 是如何來做或者是不做Generation garbage collection 這個老泰就不清楚了。

Garbage Collection 的功能主要是用來監測Garbage Collector 的負載。至於什麼叫做負載過重,這個老泰也不知道...哈哈哈,請大家自己判斷囉。而根據手冊上的介紹,如果發現過多的資源花費在Garbage Collection 時,這表示有過多的暫存物件被產生,所以可以透過一些方式來定位哪些Object,在什麼Method 所建立的。這可以用來將Code 最佳化,並減少不必要的暫存物件產生。下圖是有關Garbage Collection 的相關圖表頁面。該頁面分成三個部分:GC 所耗費的時間、Minor collection、與Major collection。



有關Minor 與Major collection 的差異,老泰也不是非常的清楚。唯一知道的是,Major collection 時會暫停所有的Thread 以便來'清理'整個Heap Memory。所以可以由此而知Major collection 對整個系統Performance 的影響是相當大的。至於何時會啟動Major collection?老泰看了一些文章,似乎沒有一篇寫的是一樣的,所以相當的混淆。當然,有關於Grabage Collector 的Implement 本來就是每個JVM implementation 不盡相同,所以說法不見得一致。

大部分的Profiler 都有提供有關目前Class 載入的數量。YourKit 也不例外,如下圖所示。這個功能到目前為止,老泰還沒能感受到他真正的用處。不過該功能可以與Memory Usage 的資訊來做相互參考。因為載入的Classes 是被放置在Non-Heap Memory 中。所以如果發現Non-Heap Memory 的使用過大時,可以檢查一下是否是因為AP 的Classes 過多所造成的。



同樣的大部分的Profiler 也都有提供目前Thread 的數量,以供監測。YourKit 提供了基本的Thread 數量的資訊,但是有關其它Thread 相關的功能,可以說是相當的薄弱。有些Profiler 除了這個基本的功能外,對Thread 的部分還加上了Thread lock 監控、Thread 狀態等,如JProfiler、JRockit 等。Thread 的數量對我們有什麼意義?老泰說:『就是要看現在有多少Thread 還活著,Thread 數量的高峰在哪裡』。真是廢話!說了跟沒說一樣。

Thread 的數量影響著整個系統的Performance。Thread 過多,會造成CPU 的Switch Cost 過高,所以分配給每個Thread 的時間自減少。Thread 過少,會造成CPU utilization 過低,浪費了CPU 的能力。Steven Haines 的"Pro Java EE 5 Performance Management and Optimization"一書中有詳細的說明,老泰就不多嘴了。而這個功能是否對Performance tunning 有幫助呢?這個老泰目前還沒有感受到,也正在摸索中,請大家自己判斷囉。



老泰對Thread 的檢測曾經吃過一次苦頭。有個客戶發生一件奇怪的現象,就是AP 大約Run 個三天,就會發現Client 向Server 發出的Request 沒有都反應,但是卻沒有任何Exception。老泰到了現場,才發現。現場只要發生No response 的情況,Thread 的數量會持續的遞增。想想如果發生這種情況,YourKit 了不起只能顯示出Thread 數量的異常,但是卻沒有辦法協助來定位問題點。不過當然還是有別的辦法取得當下Thread 的狀況啦,但是如果有工具的話會就方便。

最後,有關Telemetry 的部分。YourKit 提供一個Summary 的介面,以方便來看到這個AP 目前的整體狀況,如下圖。這個頁面大略顯示出上面所有提到有關該AP 的概要資訊。




Resources





標籤: , ,

0 個意見:

張貼留言

訂閱 張貼留言 [Atom]



<< 首頁