原因：應用啟動後，在未做呼叫時cpu占用20%-30%
開始排查。
下面將詳細寫出排查和分析過程。
1，確認問題
登入 三颱伺服器，top (或者vmstat 1)一下，檢視cpu占用情況：
三颱機器都很高，而且還未有呼叫量， 有問題。
登入imsi銷售介面伺服器對比檢視：
可以確定應用不正常了。開始解決。
2，解決過程
發現大量的nettyclientselector， 嗯？ 這應該是hsf的執行緒吧！（這裡分析是錯的！！！） 然而忽略了最重要的mq-asyncarraydispatcher-thread-xx，這個後面會詳細寫。
然後後面做了一些對hsf的配置優化，進入edas的後台可以檢視到有大量的無用的consumer，這對edas的壓力是非常大的，隨著以後服務越來越多，配置越來越多，會對線上存在隱患，於是進行精簡，抽取本地的 consumer配置檔案。
再次上線， 分析。。 發現問題依舊， 崩潰。 從頭再來。
發現查了好多都是 asyncarraydispatcher$asyncrunnable.run 這個方法。
繼續分析這個東西是幹嘛的，找**。
發現這是乙個守護執行緒，應該是為每個新建立的topic 提供一些系統的記錄功能。
瓶頸期到了，想找找**應用到了這個類，可是都在阿里的jar裡，找起來很費勁，而且不確定在哪，有可能還會在潘多拉裡，找了很久的class原始碼，無果，這裡耽誤了很久的時間。
後來轉換方向，因為imsi_sale是正常的，所以確定不會是底層的bug導致的，還是把目標轉向應用本身的配置，而且跟mq相關的。
檢視mq相關的配置，驚奇的發現，竟然這麼多無用配置。
將近 100多，期間我們找了天源的人給看了topic的預設執行緒數是5個，這麼算來也得啟了幾百的無用執行緒，跟問題執行緒數也很接近。
到底是不是呢？ 又找了**，發現在 base_impl包裡真的有：
不得不說隱藏的很深，有點坑。 這些東西應該是放在配置檔案裡，我們能看見的地方的。
好吧，終於確定問題了，精簡配置檔案，上線， 解決！
注： 其他應用也存在這樣的問題， 都需要修復一下。
CPU常用引數調優
cpu 時間片長，優先順序低 io 時間片短，優先順序高 檢視cpu實時狀態命令 top w vmstat 1 5 uptime sar q 可以實時取樣也可以檢視過去cpu使用情況 檢視cpu使用率命令 mpstat 可檢視指定的cpu使用率，也可檢視全部cpu使用率 sar p all 1 2 ...
CPU調優併發問題
多核cpu 讓指定的程式 在指定的cpu上執行 看的是程序型別 cpu消耗型 i o消耗型 多執行緒併發 乙個程式執行 我使用到兩個cpu核心 我們可以讓改程式以執行緒方式執行 每 個核心執行乙個執行緒 多核情況下以執行緒方式執行效果更好一些,單核的話區別就不大了 測試 io消耗型 bin bash...
linux 多核CPU效能調優
常常感覺系統資源不夠用，一台機子上跑了不下3個比較重要的服務，但是每天我們還要在上面進行個備份壓縮等處理，網路長時間傳輸，這在就很影響本就不夠用的系統資源 這個時候我們就可以把一些不太重要的比如copy 備份 同步等工作限定在一顆cpu上，或者是多核的cpu的一顆核心上進行處理，雖然這不一定是最有效...