應用伺服器CPU高效能定位和排查

2022-10-04 01:54:11 字數 1686 閱讀 8032

本課程的主旨及目標

•導致應用cpu高的常見原因

•定位問題的大體思路

•定位問題的具體方法

•實際案例

應用cpu高常見原因

•1.程式計算比較密集

•2. 程式死迴圈、死鎖

•3.程式邏請求堵塞

•4.io讀寫太高 (df –h看看磁碟是不是滿了)

•5.自創執行緒沒有限制(執行緒池)

•6.不合理的建立物件,導致頻繁gc

定位問題的具體方法

1.不管什麼情況先用top命令檢視資源消耗,找到消耗大量cpu資源的程序pid,我們一般都是j**a程序排名第一

2.輸入top –p pid 來單獨監控該程序

3.在第2步的監控介面輸入h,獲取當前程序下的所有執行緒資訊

4.找到消耗cpu特別高的執行緒編號(可能會有多個),這裡是6752

5.將第4步得到的執行緒編號6752轉成16進製制是1a60,因為jstack輸出的執行緒棧資訊中,執行緒id是以十六進製制展示的。

6.切換到jbossuser使用者【pid對應的程序使用者,這裡一般是j**a程序使用者】

7.因為沒有jstack這個檔案的環境變數,所以要先export path="$path:/opt/wildfly/openjdk/openjdk-1.8.0_92/bin"

9.通過jstack命令來檢視下當前記憶體狀態,解讀執行緒資訊,定位具體**位置,接下來就是找開發人員確認問題,看這段**是否可以優化。

實際案例

案例一:

定位到cpu過高是io讀寫太高 ,接下來就是找開發人員確認這段**是否可以優化

案例二:

兩個執行緒執行過程中,需要對兩個物件進行加鎖,且加鎖的順序不一致,導致了死鎖的產生,簡單的修復方法是:對兩個物件的加鎖順序一致。

注意:必須有兩個可以被加鎖的物件才能產生死鎖,只有乙個不會產生死鎖問題

案例三:

案例四:

案例五:

1.生產環境heap堆記憶體不斷上公升導致oom,pst環境復現heap堆記憶體不斷上公升。經過分析堆記憶體建立的windq主題或佇列windqqueue、windqtopic方式會快取到連線工廠,快取的物件並不是根據唯一的key去快取,而是直接使用物件的引用作快取,導致jvm無法**這部分記憶體(比如新建同乙個sendoperationtopic的主題object1,object2,object1和object2都會快取到連線工廠)。

2.pst環境百萬資料重試發現棧記憶體溢位,由於遞迴呼叫導致,已將遞迴方法修改為迴圈的方式去呼叫。

結果:修改後pst環境記憶體**穩定,無連線工廠大物件,堆記憶體,無棧記憶體溢位,cpu使用情況穩定。

發現程式異常前通過執行指令,直接生成當前jvm的dump檔案,15434是指jvm的程序號

效能測試應用伺服器CPU高 執行緒dump

效能測試過程中,我們會去監控資源的使用情況,一般監控哪些方面呢?1 伺服器的資源情況 cpu 記憶體 網路 執行緒 2 資料庫 慢查詢 死鎖 3 中介軟體 redis memcache rabbitmq 某日,在測試監控過程中發現,應用伺服器的cpu非常高。分析 應用cpu高,說明程序非常耗用資源,...

應用伺服器cpu,記憶體占用高

自上次解決負載均衡導致伺服器飄紅問題後,房產應用伺服器還是會時不時出現cpu負載過高的問題,並經常在半夜0點後,偶爾也在白天。開始查詢問題原因。1.哪些請求太慢?找出了一些慢請求,結果分析後,找不出導致慢的 而這些慢的請求也是在服務出問題時出現的。2.cpu高時記憶體是正常的,開始懷疑是不是因為jv...

應用伺服器安裝

1.安裝sql server 2008 r2 native client,注意區分cpu是32位還是64位的 2.copy xe2的midas到c windows system32 低版本的midas.dll會報錯 invalid package 3.命令列執行 regsvr32 midas.dll...