早上醒來便被系統報警簡訊施加了不小的壓力，系統夜間多次報警，cpu使用率過高（超過90%），昨天晚上確實是上線了乙個計算類的需求，不過演算法相對簡單（簡單來說就是取兩個字串的公共子串，然後做一些處理),主觀上認為不會因為這導致cpu爆掉，但是問題就是隨著這個需求出現的，肯定拖不了干係，哎，bug排查往往就是這樣，感覺某某地方不應該有問題，但是除了他又別無懷疑物件。
火急火燎的趕到公司，先申請了幾台伺服器擴容，緩解下壓力，（leader也建議先下掉這個介面，但是我觀察了這個介面的具體指標後，預估先擴下容，能撐住，撐不住再下，再則，下掉後，現象也會隨之消失，更不利於排查問題）
擴容後，cpu和記憶體，都降到了可以接受的程度。
開始排查
1:單台伺服器qps很低，個位數，可以放棄了。
2:想通過jstack看下，但是線上環境沒許可權執行這個命令，只能放棄
3:線下模擬，雖然感覺基本沒用，畢竟上線之前，線下已經測試了，但是死馬當作活馬醫，人總是會抱著萬一的想法的，不過現實並不理想，由於沒有跳出之前測試的思路，再次測試並沒有突破。
截圖如下：
根據堆疊資訊，找到相關**，截圖如下：
**相對來說簡單，但從**來看，除了list的遍歷寫的不太友好（具體就不細說了，都應該能看出來）之外，並看不出什麼。算了，先把能看到的解決了，
但是上線之後，問題依舊的話豈不是很尷尬，先測試下兩種方式的效果再說吧，簡單測試，發現list長度上萬之後，效率才有差異，果斷放棄這條線了（並不是不改，而是接著排查原因），這樣基本就沒啥可排查了，只有list很大了可查了，但是主觀上是不信的，再大能有多大呢。按照之前的測試**debug之後，list長度並無問題，測試和線上不一樣的，也就只有入參了，對了，入參，去線上log中找了cpu報警時的入參，有亮點，比測試環境長很多，好歹有可測的地方了，debug之後，果然，這個入參，查處的list的size竟然有將近7千，其中絕大部分都是空，後面就好定位了，演算法邏輯有問題，在入參較長的情況下，很容易暴漏出來（這個需求的場景中，一把都很短，自測也確實不夠全面），修復之後，cpu降至個位數，搞定。
回頭來看，問題本身很簡單，但是前後排查缺花了近2個小時，讓自己長個急性，留個爪
為什麼cpu佔用率非常高
乙個簡單的點燈任何ledtask，看起來cpu佔用率不高，但在這個任務起來後，整個系統的cpu佔用率會變得很高。經查，原因是這段code char cmd 64 sprintf cmd,opt ipnc gpiotst d setmode out pin system cmd sprintf cmd...
Mac 環境 Vue 開發 CPU 佔用率高 問題
mac開發vue應用時，發現cpu風扇轉的老高。htop檢視一下 問題找到了，就是這個dev server.js，node起的程序。然後就是 dtruss p 1230 程序id 命名跟蹤一下這個程序，發現一直在讀取應用下的每個js檔案。ps aux grep node grep v grep aw...
linux問題排查 高cpu佔用率的程序和執行緒
1.簡介 乙個程式，完成它預設的功能，並不能說明它是乙個優良的程式。好的程式，應該是對資源的合理利用，亦或是 用更少的資源 使用合理的演算法 實現更多有效的產出。影響程式的資源一般而言分為4個 cpu 記憶體 io 網路。本文著重講解一下在linux系統下，如何檢視高cpu佔用率的程序，執行緒。2....