學習大神的http://mp.weixin.qq.com/s/hXtCzSnlVfo9Cq92538ipw自己整理一點思路
1.0top看cpu消耗,發(fā)現sys比usr要高不少，這非常不正常

在宛城等地區(qū)，都構建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統性、市場前瞻性、產品創(chuàng)新能力，以專注、極致的服務理念，為客戶提供成都網站設計、做網站 網站設計制作按需制作,公司網站建設,企業(yè)網站建設,品牌網站制作,營銷型網站建設,外貿網站制作,宛城網站建設費用合理。

1.1使用pstack看 MySQL所有線程的調用棧:

InnoDB線程同步機制

我們知道linux線程同步有Mutex,spin lock,條件變量,rw lock等多種同步機制，InnoDB并沒有直接使用系統的同步機制，而是自己定義了互斥結構數據結構kernel_mutex,將系統的spin lock,mutex,和條件變量融合一起

如圖,kernel_mutexmutex對象的中重要的結構成員為os_event和lock_word。

• kernel_mutex主要涉及mutex_create,mutex_enter,mutex_exit函數，會分別使用glibc的malloc()和free()調用動態(tài)分配和釋放內存

• 封裝mutex和條件變量，圖中綠色框區(qū)域
  MySQL線程之間發(fā)送異步信號來進行同步主要通過os_event_struct結構體中的os_mutex(封裝os的pthread_mutex_t)和cond_var(封裝os的pthread_cond_t)成員對象實現。當InnoDB在獲取鎖的時候，首先先努力自旋一段時間，如果超過innodb_sync_spin_loops的閾值，就會通過函數os_event_wait_low()在os_event_struct->cond_var上等待。如圖，當某個線程釋放了鎖的時候，通過os_cond_broadcast嘗試發(fā)送廣播喚醒所有等待os_event_struct->cond_var條件變量的線程.這些線程被喚醒后又繼續(xù)競爭爭搶os_event_struct->os_mutex

• spin lock，圖中黃色框區(qū)域
  通過lock_word做spin wait。線程想要爭搶鎖的時候先判斷這個值，如果lock_word為1就繼續(xù)自旋等待。如果發(fā)現其他線程釋放了鎖該值變?yōu)?的時候，就通過test_and_set改為1，"告訴"其他線程這把鎖被持有了

InnoDB這樣設計的目的都是延緩線程被掛起并進入os wait的速度，因為每一次進入os wait等待被喚醒或者喚醒都會進行一次上下文切換.但是也只能是延緩，并不能阻止，如果持續(xù)惡化得不到環(huán)境，最后仍然會進入os的等待隊列，將會產生大量的上下文切換。但是有兩個問題:

• kernel_mutex是個全局鎖，保護事務，buffer pool,鎖，等InnoDB存儲引擎實現的大部分對象.當MySQL突然有大量訪問，并發(fā)一旦非常高的時候，mutex沖突非常劇烈，此時臨界區(qū)變得非常大，同時也會浪費cpu很多時間空轉。所以這也解釋了sys cpu大量消耗在自選空轉中

• 并且并發(fā)高的時候會頻繁調用malloc()申請內存，而glibc本身的malloc()本書頻繁調用系統mutex_lock()和unlock()，在多線程高并發(fā)場景下并且資源不足的場景下，也會造成系統各種mutex競爭嚴重。大量線程被掛起等待os pthread_cond_broadcast廣播被喚醒，隨之而來的是大量的上下文切換

通過dstat看到此時cpu每秒有近20W次的上下文切換，綜上所述，sys cpu負載高主要以下:

• (1)cpu內核態(tài)spin,大量線程cpu在內核態(tài)自旋等待

• (2)系統上下文切換,又分為:

• spin仍然失敗的，最終進入os wait，調用pthread_cond_wait等待條件滿足時被喚醒

• malloc()頻繁加減os mutex，且系統內存緊張

當前題目：【Mysql】主機cpu之-sys使用率過高-創(chuàng)新互聯
文章來源：http://weahome.cn/article/jdodc.html