CPU調優總結

緣由：應用啓動後，在未作調用時cpu佔用20%-30%

這確定是有問題的，嚴重影響壓測質量和存在線上風險，因此開始排查。

下面將詳細寫出排查和分析過程。

 

1，確認問題

登陸 三臺服務器，top (或者vmstat 1)一下，查看cpu佔用狀況：

三臺機器都很高，並且還未有調用量， 有問題。

登陸IMSI銷售接口服務器對比查看：

能夠肯定應用不正常了。開始解決。

 

2，解決過程

• 由於是cpu高，內存不高，因此肯定是線程問題，因此去到問題服務器抓取線程
  
  ./jstack  xx >> /home/admin/jstack.log    （xx 是應用的進程號）
  將線程日誌搞到跳板機 再搞到本地分析。
  
  線程分析工具用的是 jca，打開查看：
  
  
  而正常的應用:
  
  
  問題應用runnable 線程居然有900多，waite線程不會佔用cpu資源，暫時不用分析。點擊詳細：
  
  

      

          發現大量的NettyClientSelector， 嗯？ 這應該是hsf的線程吧！（這裏分析是錯的！！！） 然而忽略了最重要的MQ-AsyncArrayDispatcher-Thread-XX，這個後面會詳細寫。

          而後後面作了一些對hsf的配置優化，進入edas的後臺能夠查看到有大量的無用的consumer，這對edas的壓力是很是大的，隨着之後服務愈來愈多，配置愈來愈多，會對線上存在隱患，因而進行精簡，抽取本地的 consumer配置文件。

           再次上線， 分析。。 發現問題依舊， 崩潰。  從頭再來。 

• 仍是找到問題進程
  
  咱們看看這個進程裏的哪些線程在佔用cpu：
  top -p 進程id -H
  
   (這個圖是解決問題後截取的，沒解決時，cpu佔比每一個都在0.6-1左右，是很是高的)
  
  紅框裏是線程id，是10進制的，jstack.log 裏是以16進制展現的，因此須要轉換，到文件裏找到對應的線程號。

          

發現查了好多都是 AsyncArrayDispatcher$AsyncRunnable.run 這個方法。

繼續分析這個東西是幹嗎的，找代碼。

發現這是一個守護線程，應該是爲每一個新建立的topic 提供一些系統的記錄功能。

瓶頸期到了，想找找哪裏應用到了這個類，但是都在阿里的jar裏，找起來很費勁，並且不肯定在哪，有可能還會在潘多拉里，找了好久的class源碼，無果，這裏耽誤了好久的時間。

後來轉換方向，由於imsi_sale是正常的，因此肯定不會是底層的BUG致使的，仍是把目標轉向應用自己的配置，並且跟MQ相關的。

查看mq相關的配置，驚奇的發現，居然這麼多無用配置。

 。。。

將近 100多，期間咱們找了天源的人給看了topic的默認線程數是5個，這麼算來也得啓了幾百的無用線程，跟問題線程數也很接近。

究竟是不是呢？ 又找了代碼，發如今 base_impl包裏真的有：

 

不得不說隱藏的很深，有點坑。 這些東西應該是放在配置文件裏，咱們能看見的地方的。

好吧，終於肯定問題了，精簡配置文件，上線， 解決！

注： 其餘應用也存在這樣的問題， 都須要修復一下。