摘要:背景最近時運不佳,幾乎天天被線上問題騷擾。工具分析所以最好的方式就是不改動一行代碼把這個問題分析出來。我們選用了阿里以前開源的來使用。因為這個項目阿里多年沒有維護了,還殘留一些我在它原有的基礎上修復了個影響使用的,同時做了一些優(yōu)化。
背景
最近時運不佳,幾乎天天被線上問題騷擾。前幾天剛解決了一個 HashSet 的并發(fā)問題,周六又來了一個性能問題。
大致的現(xiàn)象是:
我們提供出去的一個 OpenAPI 反應時快時慢,快的時候幾十毫秒,慢的時候幾秒鐘才響應。嘗試解決
由于這種也不是業(yè)務問題,不能直接定位。所以嘗試在測試環(huán)境復現(xiàn),但遺憾的測試環(huán)境賊快。
沒辦法只能硬著頭皮上了。
中途有抱著僥幸心里讓運維查看了 Nginx 里 OpenAPI 的響應時間,想把鍋扔給網(wǎng)絡。結(jié)果果然打臉了;Nginx 里的日志也表明確實響應時間確實有問題。
為了清晰的了解這個問題,我簡單梳理了這個調(diào)用過程。
整個的流程算是比較常見的分層架構(gòu):
客戶端請求到 Nginx。
Nginx 負載了后端的 web 服務。
web 服務通過 RPC 調(diào)用后端的 Service 服務。
日志大法我們首先想到的是打日志,在可能會慢的方法或接口處記錄處理時間來判斷哪里有問題。
但通過剛才的調(diào)用鏈來說,這個請求流程不短。加日志涉及的改動較多而且萬一加漏了還有可能定位不到問題。
再一個是改動代碼之后還會涉及到發(fā)版上線。
工具分析所以最好的方式就是不改動一行代碼把這個問題分析出來。
這時就需要一個 agent 工具了。我們選用了阿里以前開源的 Tprofile 來使用。
只需要在啟動參數(shù)中加入 -javaagent:/xx/tprofiler.jar 即可監(jiān)控你想要監(jiān)控的方法耗時,并且可以給你輸出報告,非常方便。對代碼沒有任何侵入性同時性能影響也較小。
工具使用下面來簡單展示下如何使用這個工具。
首先第一步自然是 clone 源碼然后打包,可以克隆我修改過的源碼。
因為這個項目阿里多年沒有維護了,還殘留一些 bug,我在它原有的基礎上修復了個影響使用的 bug,同時做了一些優(yōu)化。
執(zhí)行以下腳本即可。
git clone https://github.com/crossoverJie/TProfiler mvn assembly:assembly
到這里之后會在項目的 TProfiler/pkg/TProfiler/lib/tprofiler-1.0.1.jar 中生成好我們要使用的 jar 包。
接下來只需要將這個 jar 包配置到啟動參數(shù)中,同時再配置一個配置文件路徑即可。
這個配置文件我 copy 官方的解釋。
#log file name logFileName = tprofiler.log methodFileName = tmethod.log samplerFileName = tsampler.log #basic configuration items # 開始取樣時間 startProfTime = 1:00:00 # 結(jié)束取樣時間 endProfTime = 23:00:00 # 取樣的時間長度 eachProfUseTime = 10 # 每次取樣的時間間隔 eachProfIntervalTime = 1 samplerIntervalTime = 20 # 端口,主要不要沖突了 port = 50000 debugMode = false needNanoTime = false # 是否忽略 get set 方法 ignoreGetSetMethod = true #file paths 日志路徑 logFilePath = /data/work/logs/tprofile/${logFileName} methodFilePath =/data/work/logs/tprofile/${methodFileName} samplerFilePath =/data/work/logs/tprofile/${samplerFileName} #include & excludes items excludeClassLoader = org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader # 需要監(jiān)控的包 includePackageStartsWith = top.crossoverjie.cicada.example.action # 不需要監(jiān)控的包 excludePackageStartsWith = com.taobao.sketch;org.apache.velocity;com.alibaba;com.taobao.forest.domain.dataobject
最終的啟動參數(shù)如下:
-javaagent:/TProfiler/lib/tprofiler-1.0.1.jar -Dprofile.properties=/TProfiler/profile.properties
為了模擬排查接口響應慢的問題,我用 cicada 實現(xiàn)了一個 HTTP 接口。其中調(diào)用了兩個耗時方法:
這樣當我啟動應用時,Tprofile 就會在我配置的目錄記錄它所收集的方法信息。
我訪問接口 http://127.0.0.1:5688/cicada-example/demoAction?name=test&id=10 幾次后它就會把每個方法的明細響應寫入 tprofile.log。
由左到右每列分別代表為:
線程ID、方法棧深度、方法編號、耗時(毫秒)。
但 tmethod.log 還是空的;
這時我們只需要執(zhí)行這個命令即可把最新的方法采樣信息刷到 tmethod.log 文件中。
java -cp /TProfiler/tprofiler.jar com.taobao.profile.client.TProfilerClient 127.0.0.1 50000 flushmethod flushmethod success
其實就是訪問了 Tprofile 暴露出的一個服務,他會讀取、解析 tprofile.log 同時寫入 tmethod.log.
其中的端口就是配置文件中的 port。
再打開 tmethod.log :
其中會記錄方法的信息。
第一行數(shù)字為方法的編號。可以通過這個編號去 tprofile.log(明細)中查詢每次的耗時情況。
行末的數(shù)字則是這個方法在源碼中最后一行的行號。
其實大部分的性能分析都是統(tǒng)計某個方法的平均耗時。
所以還需要執(zhí)行下面的命令,通過 tmethod.log tprofile.log 來生成每個方法的平均耗時。
java -cp /TProfiler/tprofiler.jar com.taobao.profile.analysis.ProfilerLogAnalysis tprofiler.log tmethod.log topmethod.log topobject.log print result success
打開 topmethod.log 就是所有方法的平均耗時。
4 為請求次數(shù)。
205 為平均耗時。
818 則為總耗時。
和實際情況是相符的。
方法的明細耗時這是可能還會有其他需求;比如說我想查詢某個方法所有的明細耗時怎么辦呢?
官方?jīng)]有提供,但也是可以的,只是要麻煩一點。
比如我想查看 selectDB() 的耗時明細:
首先得知道這個方法的編號,在 tmethod.log 中可以看查到。
2 top/crossoverjie/cicada/example/action/DemoAction:selectDB:84
編號為 2.
之前我們就知道 tprofile.log 記錄的是明細,所以通過下面的命令即可查看。
grep 2 tprofiler.log
通過第三列方法編號為 2 的來查看每次執(zhí)行的明細。
但這樣的方式顯然不夠友好,需要人為來過濾干擾,步驟也多;所以我也準備加上這樣一個功能。
只需要傳入一個方法名稱即可查詢采集到的所有方法耗時明細。
總結(jié)回到之前的問題;線上通過這個工具分析我們得到了如下結(jié)果。
有些方法確實執(zhí)行時快時慢,但都是和數(shù)據(jù)庫相關(guān)的。由于目前數(shù)據(jù)庫壓力較大,準備在接下來進行冷熱數(shù)據(jù)分離,以及分庫分表。
在第一步操作還沒實施之前將部分寫數(shù)據(jù)庫的操作改為異步,減小響應時間。
考慮接入 pinpoint 這樣的 APM工具。
類似于 Tprofile 的工具確實挺多的,找到適合自己的就好。
在還沒有使用類似于 pinpoint 這樣的分布式跟蹤工具之前應該會大量依賴于這個工具,所以后續(xù)說不定也會做一些定制,比如增加一些可視化界面等,可以提高排查效率。
你的點贊與分享是對我最大的支持
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/72115.html
摘要:任務四一個最常見的移動端頁面完成的事情完成簡單布局,然后填充界面與效果圖對比優(yōu)化完成驗收要求擴展性頂欄固定進行樣式兼容性研究完成任務四深度思考跟隨深度思考師兄建議進行修改輸入欄左側(cè)換用輸入限制電話位,密碼位根據(jù)結(jié)構(gòu)的語義化修改嘗試下再加一 任務四、 一個最常見的移動端頁面 完成的事情 完成簡單布局,然后填充界面 與效果圖對比優(yōu)化 完成驗收要求:header擴展性 & 頂欄固定 進行p...
摘要:現(xiàn)在在后端業(yè)務開發(fā)編程方面,技術(shù)力量強的團隊已經(jīng)開始將技術(shù)棧從同步模式切換為異步了。使用這些技術(shù)方案是無法兼容已有程序的。影響了異步回調(diào)技術(shù)棧的普及。將會成為未來后端開發(fā)領(lǐng)域的主流技術(shù)方案。 今天太忙,少寫一點,后面再補充。 異步模式 Go 語言越來越熱門,很多大型互聯(lián)網(wǎng)公司后端正在轉(zhuǎn)向 GO 。Java 圈知名的服務化框架 Dubbo 也宣布轉(zhuǎn)型異步模式。這是一個大趨勢,異步模式已經(jīng)...
摘要:背景容器數(shù)量過高,可能的原因有請求的不合理調(diào)用,本身的性能問題等,目前的問題難以定位,所以準備出一個的分析資源消耗。需求可視化的形式查看整體的響應時間占比,定位大頭優(yōu)先消除。所以找面積最大的追蹤查看即可。 背景: qa 容器數(shù)量過高,可能的原因有 api 請求的不合理調(diào)用,api 本身的性能問題等,目前的問題難以定位,所以準備出一個 qa 的 profile 分析資源消耗。 需求 可視...
使用phpAnalysis打造PHP應用非侵入式性能分析器,查找PHP性能瓶頸。 什么是phpAnalysis phpAnalysis是一款輕量級非侵入式PHP應用性能分析器,適用于開發(fā)、測試及生產(chǎn)環(huán)境部署使用,方便開發(fā)及測試工程師診斷性能問題: 通過tideways收集PHP程序單步運行過程中所有的函數(shù)調(diào)用時間及CPU內(nèi)存消耗等信息 信息永久存儲到MySQL數(shù)據(jù)庫 分析每個請求執(zhí)行的信息,幫助...
閱讀 1008·2021-09-30 09:58
閱讀 2836·2021-09-09 11:55
閱讀 2004·2021-09-01 11:41
閱讀 995·2019-08-30 15:55
閱讀 3355·2019-08-30 12:50
閱讀 3499·2019-08-29 18:37
閱讀 3297·2019-08-29 16:37
閱讀 2017·2019-08-29 13:00