最近博主在搬磚的時候遇到了線上的一些問題,大致情況是這樣的。表象:服務掛了,cpu占用比較高,一直在百分之九十多。肯定有小夥伴會說常規操作 ,reboot一下完事兒了。其實這樣吧沒毛病,但是解決不了根本問題。啥也不多說。咱們先說下線上排查三板斧。就算不能解決問題也能猜個差不多。
top -hp
命令找出執行緒 pid-threadprintf '%x\n'
命令將執行緒 pid 轉換成 16 進製 pid-thread-hex
jstack | grep 'pid-thread-hex'
命令檢視執行緒資訊 示例
應用 pid 為 10195
執行緒 pid 為17316
printf '%x\n'
命令將執行緒 pid 轉換成 16 進製pid-thread-hex
43a4
其實我們看這個他正在執行。顧名思義-->執行緒一直沒結束,死迴圈了。
截止到這我們其實只是找到了那個cpu高的執行緒,從上面也沒發現什麼東西,接下來重點來了。有幾個方向可以去做,gc情況,磁碟io,或者資料庫的情況,這些都是需要考慮的地方。別忘了,我們要保留好現場。保留當時的堆疊資訊,保留好當時的記憶體占用情況。
指令:jstack -l [pid] > /path/[pid].stack
這裡面的pid是應用pid,即上面說的 10195。從堆疊上看一下當前都那些執行緒正在執行,cat 10195.stack | grep runnable -c 20
分析到這結合上面可能是死迴圈,這裡面顯示gc又頻繁,還發現了正在執行的業務**,內心:曹尼瑪,誰寫的坑逼業務**,都到這了還不讓我找出來,我決定分析一下記憶體資訊,看一看。
指令:jmap -heap [pid]
由於記憶體資訊比較大,我們只匯出應用pid的記憶體資訊。緊接著我們用mat工具分析一下,不會分析的小夥伴,要學習一下了,這也是乙個比較好的提示。
注:eclipse memory analyzer eclipse 提供的乙個用於分析jvm 堆dump
檔案的外掛程式。借助這個外掛程式可檢視物件的記憶體占用狀況,引用關係,分析記憶體洩露等。
mysql 占用cpu過高
mysql 最近因使用者訪問量的增大和資料的增多,導致占用cpu過大,甚至可達100 所以,在網上找了些資料,進行cpu的優化 1.修改my.ini的 tmp table size 原來的 tmp table size 竟然為18m 汗.將其值修改為200m tmp table size 200m2...
實戰CPU占用過高問題定位
網上學習了cpu 占用過高如何快速定位的方法後,根據現有的專案實戰一次。廢話不多說了,直接展示定位的問題的詳細步驟。服務部署在linux伺服器,定位問題的方法,主要也是使用相關的linux命令與jdk檢視堆疊,gc日誌等相關命令。1.問題發現 top 檢視當前伺服器各個程序執行占用cpu,記憶體等情...
分析CPU佔用率過高的問題
cpu佔用率過高的原因 1 中存在死迴圈 2 演算法過於複雜。對於演算法過於複雜而導致的cpu佔用率過高的問題,分析起來並不容易。下面提供一種方法,不管你對 的邏輯以及業務的需求是否了解,只要掌握了這種方法,都可以將問題定位出來。我們都知道,在linux unix下都有效能統計工具,通過top命令,...