背景：通過效能監控發現上線伺服器cpu某核佔用率已經達到了100%，而且是由我們的某個核心服務導致的。幸虧由於我們的服務程序由多個相同worker（執行緒）排程承擔的，所以除了cpu佔用率高之外，並沒有對服務造成影響。隨著上次我們找到那個吃io的罪犯，這次我們要追捕的是潛伏在團體中的特務，更加驚險刺激喲！
系統環境
用top命令很容易定位到是誰占用cpu最高。
以我們的這個業務程序（imdevserver）舉例，為什麼說這貨是個潛伏者呢？因為這是個多執行緒的程序，我們要知道實際上占用cpu的最小單位是執行緒，所以肯定是眾執行緒中的某乙個或幾個占用cpu過高導致的。top -h -p pid命令檢視程序內各個執行緒占用的cpu百分比
如上圖所示我們可以看出id為8863的執行緒cpu佔用率最高。好，我們現在只要能找到他偷走的cpu就好了，雖然這小子嘴巴嚴，但是我們有一套完善的審問流程，不怕他不招。首先出馬的是strace -t -r -c -p pid命令
它的作用是檢視系統呼叫和花費的時間，epoll_wait雖然占用的呼叫時間多，但是他本身是個正常的阻塞呼叫。
我們接著讓pstack pid出馬
可以看到每個執行緒的呼叫堆疊，找到已經找出的占用cpu最高的那個執行緒，然後看他的呼叫堆疊，很容易看出在哪一步邏輯上導致了busy loop，
再使用trace -p tid看看執行緒的呼叫過程接著定位到**，修復bug，找回被偷走的cpu。
後記：其實作為乙個程式設計師，我感覺最大的樂趣不是洋洋灑灑的寫程式，而是去尋找一些「高階」bug，也許就和有些刑警痴迷於偵破案件一樣，這就是對技術的熱愛。
一次伺服器CPU佔用率高的定位分析
ps h e o pid,tid,pcpu,cmd sort pcpu grep freeswitch背景 通過效能監控發現上線伺服器cpu某核佔用率已經達到了100 而且是由我們的某個核心服務導致的。幸虧由於我們的服務程序由多個相同worker 執行緒 排程承擔的，所以除了cpu佔用率高之外，並沒...
一次伺服器IO佔用率高的定位分析
檔案系統 資料庫 如果innodb flush log at trx commit設定為1，每次事務提交時mysql都會把log buffer的資料寫入log file，並且flush 刷到磁碟 中去.如果innodb flush log at trx commit設定為2，每次事務提交時mysql...
一次伺服器IO佔用率高的定位分析
檔案系統 資料庫 高效能mysql 這本書的第10章 複製的章節 從上面的環境描述中可以看到我使用了mysql的主主複製 找到了對sync binlog的說明 如果innodb flush log at trx commit設定為1，每次事務提交時mysql都會把log buffer的資料寫入log...