我相信做技術(shù)的都會(huì)遇到過這樣的問題，生產(chǎn)環(huán)境服務(wù)遇到宕機(jī)的情況下如何去分析問題？比如說JVM內(nèi)存爆掉、CPU持續(xù)高位運(yùn)行、線程被夯住或線程deadlocks，面對(duì)這樣的問題，如何在生產(chǎn)環(huán)境第一時(shí)間跟蹤分析與定位問題很關(guān)鍵。下來讓我們看看通過如下步驟在第一時(shí)間分析問題。

CPU占用較高場景

收集當(dāng)前CPU占用較高的線程信息，執(zhí)行如下命令：

top -H -p PID -b -d 1 -n 1 > top.log

或

top -H -p PID

結(jié)果如下：

上圖顯示的都是某一個(gè)進(jìn)程內(nèi)的線程信息，找到cpu消耗最高的線程id，再配合jstack來分析耗cpu的代碼位置，那如何分析呢？

先執(zhí)行jstack獲取線程信息

jstack -l PID > jstackl.log

將PID(29978)轉(zhuǎn)成16進(jìn)制：0x751a，16進(jìn)制轉(zhuǎn)換工具很多可以在線隨便搜索一個(gè)或者基本功好的自己計(jì)算。

打開jstackl.log，查找nid=0x751a的信息，這樣就定位到了具體的代碼位置，這里由于是安全原因我就不貼圖了。

通過上面的步驟就可以輕松的定位那個(gè)線程導(dǎo)致cpu過高，當(dāng)然也可以通過其他方式來定位，下面介紹一個(gè)快捷的方式

#線程cpu占用

#!/bin/bash

[ $# -ne 1 ] && exit 1

jstack $1 >/tmp/jstack.log

for cpu_tid in `ps -mp $1 -o THREAD,tid,time|sort -k2nr| sed -n '2,15p' |awk '{print$2"_"$(NF-1)}'`;do

cpu=`echo $cpu_tid | cut -d_ -f1`

tid=`echo $cpu_tid | cut -d_ -f2`

xtid=`printf "%x\n" $tid`

echo -e "\033[31m========================$xtid $cpu%\033[0m"

cat /tmp/jstack.log | sed -n -e "/0x$xtid/,/^$/ p"

#cat /tmp/jstack.log | grep "$xtid" -A15

done

rm /tmp/jstack.log

上述命令會(huì)以百分比的方式來顯示每個(gè)線程的cpu消耗百分比，這里我就不貼圖了，誰用誰知道。

內(nèi)存消耗過高場景

收集當(dāng)前活躍對(duì)象數(shù)據(jù)量信息，執(zhí)行以下命令獲取

jmap -histo:live pid > jmaplive.log

ps. jmap -histo:live 數(shù)據(jù)可以多進(jìn)行幾次，比如說間隔幾分鐘輸出一次，然后對(duì)比兩個(gè)文件的差異可以看出gc回收的對(duì)象，如果多次結(jié)果沒有差異并且gc頻繁執(zhí)行，證明剩余對(duì)象在引用無法gc回收，這時(shí)就需要對(duì)服務(wù)進(jìn)行限流給服務(wù)喘氣的機(jī)會(huì)。

或者收集dump信息，通常這種獲取方式需要較長時(shí)間執(zhí)行，并產(chǎn)生大容量的dump文件，我們會(huì)考慮逐步廢掉通過這個(gè)文件來分析。執(zhí)行以下命令獲取

jmap -dump:file=./dump.mdump pid

dump文件通過MAT工具來進(jìn)行內(nèi)存泄漏分析。

線程、內(nèi)存分析工具

上面說過通過jstack生成的線程文件是可以通過工具來直接打開可視化分析的，這里我推薦使用：tda(Thread Dump Analyzer)這個(gè)工具可以自行搜索下載。

通過jmap -dump生成的dump文件也是可以通過工具來進(jìn)行可視化分析的，這里我推薦使用MAT(Memory Analysis Tools)它可以通過eclipse plugin的方式使用或者獨(dú)立的下載安裝包使用。

生產(chǎn)環(huán)境下JAVA進(jìn)程高CPU占用故障排查

問題描述:生產(chǎn)環(huán)境下的某臺(tái)tomcat7服務(wù)器,在剛發(fā)布時(shí)的時(shí)候一切都很正常,在運(yùn)行一段時(shí)間后就出現(xiàn)CPU占用很高的問題,基本上是負(fù)載一天比一天高. 問題分析:1,程序?qū)儆贑PU密集型,和開發(fā)溝通過, ...

生產(chǎn)環(huán)境JAVA進(jìn)程高CPU占用故障排查

問題描述:生產(chǎn)環(huán)境下的某臺(tái)tomcat7服務(wù)器,在剛發(fā)布時(shí)的時(shí)候一切都很正常,在運(yùn)行一段時(shí)間后就出現(xiàn)CPU占用很高的問題,基本上是負(fù)載一天比一天高. 問題分析:1,程序?qū)儆贑PU密集型,和開發(fā)溝通過, ...

生產(chǎn)環(huán)境下JAVA進(jìn)程高CPU占用故障排查---temp

問題描述:生產(chǎn)環(huán)境下的某臺(tái)tomcat7服務(wù)器,在剛發(fā)布時(shí)的時(shí)候一切都很正常,在運(yùn)行一段時(shí)間后就出現(xiàn)CPU占用很高的問題,基本上是負(fù)載一天比一天高. 問題分析:1,程序?qū)儆贑PU密集型,和開發(fā)溝通過, ...

IBM Thread and Monitor Dump Analyzer for Java解決生產(chǎn)環(huán)境中的性能問題

這個(gè)工具的使用和 HeapAnalyzer 一樣,非常容易,同樣提供了詳細(xì)的 readme 文檔,這里也簡單舉例如下: #/usr/java50/bin/java -Xmx1000m -jar jca ...

【生產(chǎn)環(huán)境】Tomcat運(yùn)行一段時(shí)間后訪問變慢分析歷程

環(huán)境運(yùn)行一天或者幾天,網(wǎng)站訪問就很卡,手機(jī)端app訪問頁面出現(xiàn)白屏.Tomcat運(yùn)行一段時(shí)間后訪問變慢,但是cpu,內(nèi)存都正常.日志也是發(fā)現(xiàn)不了啥.... 問題的原先分析 1.環(huán)境配置(cpu,內(nèi)存, ...

[劉陽Java]_避開環(huán)境配置快速的使用Java的開發(fā)工具_第5講

我們一般學(xué)習(xí)Java都應(yīng)該遵循通過系統(tǒng)的命令工具來編譯Java程序,然后對(duì)編譯好Java程序進(jìn)行運(yùn)行,這個(gè)是非常好的習(xí)慣.但是隨著后期學(xué)習(xí)Java技術(shù)的深入我們也得像Java的IDE工具屈服.所以,可 ...

生產(chǎn)環(huán)境提升rman備份速度----啟動(dòng)塊跟蹤

生產(chǎn)環(huán)境提升rman備份速度----啟動(dòng)塊跟蹤 [環(huán)境] AIX(5300-08).oracle10g(10.2.0.1.0-64bit) [目標(biāo)] 因?yàn)樯a(chǎn)環(huán)境數(shù)據(jù)量較大,欲加快rman備份的速度 ...

java生產(chǎn)環(huán)境增量發(fā)版陷阱【原】

前言 在生產(chǎn)環(huán)境,我們?yōu)榱私档桶l(fā)版風(fēng)險(xiǎn),一般都只做增量發(fā)布,不做全量發(fā)布. 除非項(xiàng)目只有一到兩人開發(fā),對(duì)時(shí)間線和代碼脈絡(luò)結(jié)構(gòu)一清二楚,才可全量發(fā)布. 然而增量發(fā)布也是有一定隱藏陷阱在里面的,以下就是筆 ...

JAVA中調(diào)用LevelDB用于Linux和Window環(huán)境下快速存儲(chǔ)KV結(jié)構(gòu)

一.簡介 JAVA中調(diào)用LevelDB用于Linux和Window環(huán)境下快速存儲(chǔ)KV結(jié)構(gòu) 二.依賴

總結(jié)

以上是生活随笔為你收集整理的java生产问题快速定位_生产环境如何快速跟踪、分析、定位问题-Java的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。