如何快速定位Java程序性能瓶頸

codertom

我做運維也有十幾個年頭了，最近我們的CNT系統(tǒng)（CNT是我們用于記錄跳轉(zhuǎn)計數(shù)的一套系統(tǒng)）一直很慢，我們總接到很多投訴，一直很頭疼。
花了很長的時間做排查也一直找不到問題，無法解決，領(lǐng)導(dǎo)施加了很大的壓力。
這個時候開始試用的一套APM產(chǎn)品，來幫助我查找、定位和分析問題。
查看了測試結(jié)果后，從中發(fā)現(xiàn)了很多問題和很多性能瓶頸，以前從來沒有注意過的小問題也暴露了出來，一些系統(tǒng)隱患也通過直觀的界面被看到。
該系統(tǒng)使用APM后，CPU消耗增加大約2%，內(nèi)存幾乎沒有影響，對業(yè)務(wù)系統(tǒng)的性能影響很小。
一、系統(tǒng)總覽

之前沒有使用過APM，APM部署完成后，登陸后通過dashboard，直觀地了解到系統(tǒng)整體的運行情況。從中看到了CNT系統(tǒng)的平均響應(yīng)時間，性能指數(shù)和壓力，響應(yīng)時間超過10秒。
二、問題追蹤排查
從相應(yīng)時間中發(fā)現(xiàn)，響應(yīng)過慢，需要進(jìn)一步追蹤造成該問題的原因，從事務(wù)的角度分析問題。


進(jìn)入事務(wù)的頁面，看到左側(cè)的響應(yīng)時間列表，發(fā)現(xiàn)whole_counter.jsp和counter.jsp兩個URL的平均響應(yīng)時間都在10秒左右，由此判定是這兩個文件造成響應(yīng)過慢。

從上圖的Traces中，看到所有執(zhí)行過慢的事務(wù)的開始時間和執(zhí)行時間。

上圖以whole_counter.jsp為例，深入追蹤事務(wù)的trace詳情，可以看到該事務(wù)中，執(zhí)行緩慢的函數(shù)。

進(jìn)一步追蹤執(zhí)行緩慢的函數(shù)，以javax.servlet.http.HttpServlet#service()為例，從“方法跟蹤”中查看執(zhí)行代碼。
到此為止，我們已經(jīng)定位到問題的根本所在，下一步就是根據(jù)提示的代碼行，進(jìn)行問題排查。
三，關(guān)鍵事務(wù)跟蹤

我們還是以whole_counter.jsp為例，使用關(guān)鍵事務(wù)功能對該URL進(jìn)行單獨監(jiān)控。

1，從“關(guān)鍵事務(wù)”中的“性能剖析”中，可以直觀看到該事務(wù)的相對耗用一些資源。能從中進(jìn)一步看出事務(wù)啟動時間和執(zhí)行時間。

2，在”slowest components”中，看到了所有執(zhí)行緩慢的函數(shù)、代碼以及SQL。



3，從“線程分析”中觀察時間分布圖，從中看出getAddressFromNameService在所有采樣中占比高達(dá)99.61%。


4，觀察“CPU消耗”，可以看到并不是CPU耗用的問題。

5，從“線程和鎖”來進(jìn)一步判斷問題根源，可以看到線程和鎖的采樣圖與時間分布圖完全相同，采樣占比99.61%的getAddressFromNameService方法可以判斷是線程與鎖的問題。
6，最后，通過對getAddressFromNameService方法程序進(jìn)行排查，發(fā)現(xiàn)方法中DNS解析失效，語句一直等待DNS反饋，從而導(dǎo)致業(yè)務(wù)系統(tǒng)性能緩慢。問題完滿解決，通過使用APM監(jiān)控、排查問題，使得解決問題的思路和方法更加明確，解決速度也大大提高了。

rdcwayx

樓主如果不是來做廣告的話，建議再試一下其他的APM產(chǎn)品。我當(dāng)年對差不多4款流行的APM做過評估。所有的產(chǎn)品都提倡3分鐘內(nèi)確認(rèn)root cause。

你需要比較性能，許可費用 （有按照CPU付費的， 有按照CPU core 數(shù)量付費的，有按照java instance數(shù)量付費的），實用性，易用性 等等。

pxczy

。。�？催@是廣告