1. 首頁 > 生活百科 > >

jdk下載快速方法 jdk下載慢怎么辦

生活百科線程


導語：

本文作者為解決一個JDK性能問題，從堆棧分析，到GC分析，再到Safepoint原因分析，最終定位到問題根因與所用的JDK版本有關 。并整理成文，與所有Java相關開發的同學分享此次經驗 。
01 問題來了
筆者近期在工作中遇到這樣一個問題：某客戶新上線了一個Elasticsearch應用，但運行一段時間后就變的特別慢，甚至查詢超時 。重啟后服務恢復，但每隔3～4小時后問題重現 。
針對這個問題，我身邊的同事也幫忙做了簡單分析，發現存在大量Merge的線程，應該怎么辦呢？根據我之前定位問題的經驗，一般通過Thread Dump日志分析，就能找到問題原因的正確方向，然后再分析該問題不斷重復的原因 。按照這個思路，問題分析起來應該不算復雜 。But，后來劇情還是出現了波折 。
02 困惑的堆棧日志
因網絡隔離原因，只能由客戶配合獲取Thread Dump日志 。并跟客戶強調了獲取Thread Dump日志的技巧，每個節點每隔幾秒獲取一次，輸出到一個獨立的文件中 。集群涉及到三個節點，我們暫且將這三個節點稱之為39，158，211 。問題復現后，拿到了第一批Thread Dump文件：
從文件的大小，可輕易看出39節點大概率是一個問題節點，它的Thread Dump日志明顯大出許多：查詢變慢或者卡死，通常表現為大量的Worker Thread忙碌，也就是說，活躍線程數量顯著增多 。而在ES(Elasticsearch，以下簡稱為ES)的默認查詢行為下，只要有一個節點出現問題，就會讓整個查詢受牽累 。
那么我們先對三個節點任選的1個Thread Dump文件的線程總體情況進行對比：
節點名稱39158211線程總數366341282RUNNABLE264221162WAITING648892TIME_WAITING283228BLOCKED1000再按線程池進行分類統計：
節點名稱39158211Lucene Merge Thread7700http_server_worker646464search494949transport_client_boss286430bulk323232generic1564transport_server_worker275529refresh10510management523warmer555flush555others495451可以發現：39節點上的Lucene Merge Thread明顯偏多，而其它兩個節點沒有任何Merge的線程 。
再對39節點的Thread Dump文件進行深入分析，發現的異常點總結如下：
1. Lucene Merge Thread達到77個，其中一個線程的調用棧如下所示：
2. 有8個線程在競爭鎖定ExpiringCache：
3. 有8個線程都在做HashMap#hash計算：
現象1中提到了有77個同時在做Merge的線程，但無法確定這些Merge任務是同時被觸發的，還是因為系統處理過慢逐步堆積成這樣的狀態 。無論如何這像是一條重要線索 。再考慮到這是一個新上線的應用，關于環境信息與使用姿勢的調研同樣重要：
集群共有3個節點，目前共有500 個Indices 。每個節點上寫活躍的分片數在70個左右 。按租戶創建Index，每個租戶每天創建3個Indices 。上線初期，寫入吞吐量較低 。每個索引在每分鐘Flush成的Segment在KB~數MB之間 。我開始懷疑這種特殊的使用方式：集群中存在多個寫活躍的索引，但每分鐘的寫入量都偏小，在KB至數MB級別 。這意味著，Flush可能都是周期性觸發，而不是超過預設閾值后觸發 。這種寫入方式，會導致產生大量的小文件 。抽樣觀察了幾個索引中新產生的Segment文件，的確每一次生成的文件都非常小 。

猜你喜歡