国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

Linux系統Java進程CPU高消耗問題分析

IT那活兒 / 2536人閱讀
Linux系統Java進程CPU高消耗問題分析
[
概     述
]


當應用系統出現卡頓或者應用程序響應速度非常慢的時候，我們需要登錄到應用所在主機進行查看、分析問題原因。


常用來排查Java進程問題命令：


  • 使用top命令查看主機資源總體使用情況，及相關Java進程占用主機資源情況；

  • 使用vmstat 2 5命令查看主機CPU、內存使用率；


  • 使用df -h命令查看主機文件系統使用率；

  • 使用netstat -na命令收集主機網絡連接情況；

  • 使用pstree -p PID | wc -l查看占用CPU資源較高的進程內的線程數；

  • 使用${JAVA_HOME}/bin/jstat -gcutil PID 1000 10查看占用CPU資源較高的進程GC情況；


  • 使用${JAVA_HOME}/bin/jmap -dump:live,format=b,file=PID.hprof PID導出占用CPU資源較高的進程堆快照信息，用來統計當前JVM堆中存放了哪些對象信息；


  • 使用${JAVA_HOME}/bin/jstack PID > stack_PID.log導出占用CPU資源較高的線程?？煺招畔?，來最終定位占用CPU過高的代碼模塊。


[
常見CPU高消耗原因
]


1、大量高并發密集型計算

2、高并發的I/O讀寫

3、堆內存無法有效回收，FULLGC頻繁

4、程序死循環

5、程序邏輯請求堵塞


[
分   析   方   法
]


案例1：Java進程耗用CPU高，但未觸發FULLGC的情況

1、查看進程使用CPU、MEM情況

使用命令：top

可以看到PID為4267，USER為dform的進程CPU使用率高達1464.2%（即消耗當前主機14.64個CPU），嚴重超高。使用命令cat/proc/cpuinfo | grep processor |wc –l 可查看當前主機邏輯CPU個數。


2、根據問題進程的PID查詢該進程的線程使用CPU、MEM情況

使用命令：top-p 4267-H

紅框標出的10幾個線程耗用CPU都接近或者超過了100%（即該進程下有10幾個線程耗用CPU都高達1個左右）。


3、導出問題進程的線程棧信息

使用命令：

連續導出多個線程棧（stack）快照文件，每次導出間隔5s-10s

${JAVA_HOME}/bin/jstack4267 > stack_4267_1.log

${JAVA_HOME}/bin/jstack4267 > stack_4267_2.log

${JAVA_HOME}/bin/jstack4267 > stack_4267_3.log


4、將問題線程的PID（十進制）轉換成十六進制的nid

使用命令：我們選取如下兩個線程為例


（1）線程PID4477，轉換之后的十六進制nid為117d

printf "%x "4477


（2）線程PID4542，轉換之后的十六進制nid為11be


5、根據nid在第3步中導出的線程棧（stack）快照文件中查找對應的線程



（1）根據nid=0x117d查找到正在運行的程序代碼模塊，紅框標出是該線程最后正在做的事物（線程執行順序要從下向上看），綠框標出是應用側代碼模塊。


（2）同理，根據nid=0x11be查找到正在運行的程序代碼模塊


最后將上述分析結果和線程棧（stack）快照文件一并反饋給應用側核查和處理。


案例2：Java進程耗用CPU高，而且頻繁觸發FULLGC的情況

導致Java進程頻繁FULLGC的原因有：


（1）應用代碼邏輯設計不合理，對象創建太多，而且對象使用完后未及時釋放資源，或者已不再有用的對象相互之間存在引用，導致該對象無法進行回收；


（2）消費者消費速度慢(或停止消費)，而生產者不斷往隊列中投遞任務，導致隊列中任務累積過多，任務對象占用堆內存太多而產生FULLGC；


（3）應用進程創建線程太多（每個線程需要分配線程棧內存），也可能導致內存溢出OOM，觸發FULLGC；


注：分析FULLGC的問題，除了要分析案例1中的線程棧（stack）快照信息外，還要導出JVM堆（heap）進行分析。


1、使用命令：導出JVM堆（heap）快照信息

${JAVA_HOME}/bin/jmapdump:live,format=b,file=17074.hprof17074

注：堆（heap）快照文件一般都比較大，有幾個G大?。ɑ竞蛥?Xmx設置大小一致）。


2、使用Java堆分析工具MAT（MemoryAnalyzer tool）分析堆內存中對象占用情況

通過對堆內存快照文件17074.hprof的分析，發現有以下一些對象占用內存較多：


結合日志信息分析，應用一次性經過代理節點從數據節點中獲取大量數據到堆內存中，并同時幾條請求同時進行，該代理節點出現JVM堆內數據占用較大導致內存溢出，FULLGC無法回收，此后一直頻繁FullGC。另根據GC信息分析，大約7個小時就會有一次較多請求刷新導致內存占用過多的情況。


最后將分析結果反饋給應用側核查和處理。


[
處理建議
]


1、結合中間件側分析結果應用側核查對應的代碼模塊中是否有多線程高并發或者涉及網絡間IO等，導致線程CPU耗用高的代碼，并優化；


2、結合中間件側分析結果應用側核查相應的代碼模塊所涉及的業務是否存在邏輯問題，并優化；


3、對于長時間處于CPU高消耗的進程，收集完top、線程棧（stack）快照、堆（heap）快照等信息之后，可找合適時間重啟該進程。

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/130177.html

相關文章

  • 學點虛擬化知識

    摘要：虛擬化技術是業務發展到一定階段，互聯網企業必然會使用的技術?；觳慨斎灰灿幸恍﹩栴}，例如同一臺物理機上應用被應用突來的高峰所影響，周期被搶光，莫名其妙的負載升高?；觳坑袝r也不是一開始就能規劃好的，最好能動態調整，這樣就能通過虛擬化技術來做。 showImg(https://segmentfault.com/img/bVu8fH);虛擬化技術是業務發展到一定階段，互聯網企業必然會使用的技術...

    TerryCai 評論0 收藏0

  • 對Java多線程的一些理解

    摘要：線程僅僅被視為一個與其他進程共享某些資源的進程。穩定性可創建的線程的數量上存在限制，包括的啟動參數操作系統對線程的限制，如果超出這些限制，很可能會拋出異常。若是密集型程序產生大量的線程切換，將會降低系統的吞吐量。 OS中的進程、線程 進程：即處于執行期的程序，且包含其他資源，如打開的文件、掛起的信號、內核內部數據、處理器狀態、內核地址空間、一個或多個執行的線程、數據段。 線程：進程中...

    Nekron 評論0 收藏0

發表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<