性能調優(yōu)中如何定位性能瓶頸

　　性能測試的概念是什么，基本目的是什么，我想大家都基本清楚，不作詳述，總之，性能測試只是測試過(guò)程中的一種方式，幫助我們的功能更好的運行，如果功能測試是可用，易用，滿(mǎn)足需求、用戶(hù)使用為目的，性能測試無(wú)非就是讓這些目的更流暢。沒(méi)有什么專(zhuān)業(yè)的概念，無(wú)非實(shí)現兩個(gè)字：好用!

　　所以，性能測試這種測試方式在發(fā)生過(guò)程中，其中一個(gè)過(guò)渡性的工作，就是對執行過(guò)程中的問(wèn)題，進(jìn)行定位，對功能的定位，對負載的定位，最重要的，當然就是問(wèn)題中說(shuō)的“瓶頸”，接觸性能測試不深，更非專(zhuān)家，自己的理解，瓶頸產(chǎn)生在以下幾方面：

　　1、網(wǎng)絡(luò )瓶頸，如帶寬，流量等形成的網(wǎng)絡(luò )環(huán)境

　　2、應用服務(wù)瓶頸，如中間件的基本配置，CACHE等

　　3、系統瓶頸，這個(gè)比較常用：應用服務(wù)器，數據庫服務(wù)器以及客戶(hù)機的CPU，內存，硬盤(pán)等配置

　　4、數據庫瓶頸，以ORACLE為例，SYS中默認的一些參數設置

　　5、應用程序本身瓶頸，

　　針對網(wǎng)絡(luò )瓶頸，現在冒似很少，不過(guò)也不是沒(méi)有，首先想一下如果有網(wǎng)絡(luò )的阻塞，斷網(wǎng)，帶寬被其他資源占用，限速等情況，應用程序或系統會(huì )是什么情況，針對WEB， 無(wú)非是超時(shí)，HTTP400，500之類(lèi)的錯，針對一些客戶(hù)端程序，可能也是超時(shí)，掉線(xiàn)，服務(wù)器下發(fā)的，需要服務(wù)器返回的信息獲取不到還有一種更明顯的情 況，應該就是事務(wù)提交慢，如果封裝事務(wù)的代碼再不完善，一般造成的錯誤，無(wú)非就是數據提交不完整，或者因為網(wǎng)終原因+代碼缺陷造成重復性提交。如此綜合下 來(lái)，肯定是考慮網(wǎng)絡(luò )有瓶頸，然后考慮網(wǎng)絡(luò )有問(wèn)題時(shí)，怎樣去優(yōu)化，是需要優(yōu)化交互的一些代碼，還是接口之類(lèi)的。

　　應用服務(wù)的瓶頸的定位，比較復雜，學(xué)習中， 不過(guò)網(wǎng)上有很多資料可以參考的。一般像tomcat，weblogic之類(lèi)的，有默認的設置，也有經(jīng)過(guò)架構和維護人員進(jìn)行試驗調試的一些值，這些值一般可 以滿(mǎn)足程序發(fā)布的需要，不必進(jìn)行太多的設置，可能我們認識的最基本的就是JAVA_OPTS的設置，maxThreads，time_out之類(lèi)的參數我 們做借助LR，Jemeter或webload之類(lèi)的工具，執行性能測試，尤其是對應用服務(wù)造成了壓力，如果應用服務(wù)有瓶頸，一般我們設置的 log4j.properties，日志都會(huì )記錄下來(lái)。然后根據日志，去進(jìn)一步確定應用服務(wù)的問(wèn)題

　　系 統瓶頸，這個(gè)定位雖說(shuō)比較復雜，但是有很多前輩的經(jīng)驗值參考，不作說(shuō)明，相信用LR的同行，也可以從性能記數器中得出一些指標值，加上 nagios，cacti，可以很明顯的看出系統哪些資源夠用，哪些資源明顯不夠用。不過(guò)，一般系統瓶頸的造成，是因為應用程序本身造成的。關(guān)于這點(diǎn)兒的 分析和定位，就需要歸入應用程序本身瓶頸分析和定位了。

　　現在基本所有的東東，都離不開(kāi)數據庫這個(gè)后臺，數據庫的瓶頸實(shí)在是不知道是什么概 念，數據庫管理員的工作，數據庫管理員日常做的工作，可能就是有瓶頸定位的工作，比如：查詢(xún)一下 V$sys_event，V$sysstat，v$syssql之類(lèi)的表，比對一下日常正常情況下的監控數據，看一下有沒(méi)有異常等。其他方面，我也不是太 了解。

　　應用程序瓶頸，這個(gè)是測試過(guò)程中最需要去關(guān)注的，需要測試人員和開(kāi)發(fā)人員配合執行，然后定位，我這兒做的大都是執行性的，比如會(huì )有腳本去運行，開(kāi)發(fā)人員會(huì )結合jprofiler之類(lèi)的工具，去看一下堆遍歷，線(xiàn)程剖析的情況確定哪兒有問(wèn)題。大致是這樣，沒(méi)有實(shí)際操作過(guò)

　　逐步細化分析，先可以監控一些常見(jiàn)衡量CPU，內存，磁盤(pán)的性能指標，進(jìn)行綜合分析，然后根據所測系統具體情況，進(jìn)行初步問(wèn)題定位，然后確定更詳細的監控指標來(lái)分析。

　　懷疑內存不足時(shí)：

　　方法1：

　　【監控指標】：Memory Available MBytes ，Memory的Pages/sec， page read/sec， Page Faults/sec

　　【參考值】：

　　如果 Page Reads/Sec 比率持續保持為 5，表示可能內存不足。

　　Page/sec 推薦00-20(如果服務(wù)器沒(méi)有足夠的內存處理其工作負荷，此數值將一直很高。如果大于80，表示有問(wèn)題)。

　　方法2：根據Physical Disk 值分析性能瓶頸

　　【監控指標】：Memory Available MBytes ，Pages read/sec，%Disk Time 和 Avg.Disk Queue Length

　　【參考值】：%Disk Time建議閾值90%

　　當內存不足時(shí)，有點(diǎn)進(jìn)程會(huì )轉移到硬盤(pán)上去運行，造成性能急劇下降，而且一個(gè)缺少內存的系統常常表現出很高的CPU利用率，因為它需要不斷的掃描內存，將內存中的頁(yè)面移到硬盤(pán)上。

　　懷疑內存泄漏時(shí)

　　【監控指標】：Memory Available MBytes ，Process\Private Bytes和Process\Working Set，PhysicalDisk/%Disk Time

　　【說(shuō)明】：

　　Windows資 源監控中，如果Process\Private Bytes計數器和Process\Working Set計數器的值在長(cháng)時(shí)間內持續升高，同時(shí)Memory\Available bytes計數器的值持續降低，則很可能存在內存泄漏。內存泄漏應該通過(guò)一個(gè)長(cháng)時(shí)間的，用來(lái)研究分析當所有內存都耗盡時(shí)，應用程序反應情況的測試來(lái)檢驗。

　　CPU分析

　　【監控指標】：

　　System %Processor Time CPU，Processor %Processor Time CPU

　　Processor%user time 和Processor%Privileged Time

　　system\Processor Queue Length

　　Context Switches/sec 和%Privileged Time

　　【參考值】：

　　System\%Total processor time不持續超過(guò)90%，如果服務(wù)器專(zhuān)用于SQLServer，可接受的最大上限是80-85% ，合理使用的范圍在60%至70%。

　　Processor %Processor Time小于75%

　　system\Processor Queue Length值，小于CPU數量的總數+1

　　CPU瓶頸問(wèn)題

　　1、System\%Total processor time如果該值持續超過(guò)90%，且伴隨處理器阻塞，則說(shuō)明整個(gè)系統面臨著(zhù)處理器方面的瓶頸.

　　注：在某些多CPU系統中，該數據雖然本身并不大，但CPU之間的負載狀況極不均衡，此時(shí)也應該視作系統產(chǎn)生了處理器方面的瓶頸.

　　2、 排除內存因素，如果Processor %Processor Time計數器的值比較大，而同時(shí)網(wǎng)卡和硬盤(pán)的值比較低，那么可以確定CPU 瓶頸。(內存不足時(shí)，有點(diǎn)進(jìn)程會(huì )轉移到硬盤(pán)上去運行，造成性能急劇下降，而且一個(gè)缺少內存的系統常常表現出很高的CPU利用率，因為它需要不斷的掃描內 存，將內存中的頁(yè)面移到硬盤(pán)上。)

原文轉自：http://kjueaiud.com