MySQL·專家投稿·MySQL資料庫SYSCPU高的可能性分析

問題背景

我們在管理繁忙的 MySQL 資料庫時，可能都有碰到 SYS CPU 高的經歷：系統突然 SYS CPU 高起來，甚至比 USER CPU 高很多，這時系統 QPS、TPS 急劇下降。

SYS CPU高是什麼造成的呢？主要有2種可能：
1. context switch 不高，但在核心態 spin，導致 SYS CPU 高
2. context switch 高，每秒超過 200K，有時超過1M，過多 context switch 導致 SYS CPU 高

下面我們對這兩種情況逐一分析。

context switch 不高，但在核心態 spin

MySQL 在核心態 spin，說明需要系統資源，當這個資源緊張不足時，就會在核心態 spin。

有些資源，使用者程式（或執行緒）通過執行系統調或因中斷進入核心，一般來說申請這些資源的執行時間很短，當出現資源爭用時，如果採用 sleep 再喚醒機制，代價較大，因此多采用在核心態spin的策略。

例如申請記憶體或發生缺頁中斷，沒有 free 記憶體可用時，程式或執行緒就可能在核心態先執行記憶體回收再執行記憶體分配，但系統記憶體是共享資源，分配回收時需要鎖保護，當多個程式（或執行緒）同時回收分配記憶體時。就會在核心態 spin。

當 free 記憶體不足時，可能出現這種情況。典型症狀：

1. MySQL running 高，但系統 qps、tps 下降
2. 系統 free 記憶體不足；或系統 free 記憶體充足時，但啟用了 numa 記憶體分配策略，有的節點 free 記憶體很少
3. 系統 context switch 不高
4. MySQL InnoDB 的 mutex、RWlock 查不到等待資訊
5. sar -B 顯示有 pgscand 產生

分析

當系統記憶體不足時，MySQL 突然有大量訪問，緊急需要大量記憶體，kswapd 在短時間內回收不了足夠多的 free 記憶體，或 kswapd 還沒有觸發執行，這時 MySQL 使用者執行緒就會在核心態執行記憶體回收操作，從而出現以上症狀。

sar -B 輸出中，pgscank 是表示核心執行緒 kswapd 回收記憶體，k意思是 kernel；pgscand是表示使用者程式或執行緒直接回收記憶體，d意思是direct。

解決辦法：保證系統有充足 free 記憶體可用，NUMA 環境要求每個節點都有足夠free記憶體可用。

由於 Linux 系統會盡量使用 free 記憶體，一個執行很久的 Linux 系統，free記憶體通常很少，存在大量 filecache 記憶體，但 Linux 沒有直接提供控制 filecache 佔用多少的引數，那怎麼能夠保留足夠可用的 free 記憶體，以應對突然記憶體需求呢？

對此，Linux 2.3.32+ 核心中增加一個新的引數vm.extra_free_kbytes，就是控制free記憶體的。

關於系統free記憶體，有2個重要引數：vm.min_free_kbytes 和 vm.extra_free_kbytes(2.6.32+)

vm.min_free_kbytes：系統保留給核心用的記憶體。

這個值決定 /proc/zoneinfo 中 zone 的min值。當系統 free 記憶體小於這個值時，kswapd 會回收記憶體，直到free記憶體達到/proc/zoneinfo中 high 值才停止回收；

當使用者程式或執行緒分配記憶體或發生缺頁中斷時，free 記憶體少於 vm.min_free_kbytes，會在使用者執行緒上下文中直接進行回收記憶體（pgscand）和分配記憶體。

vm.extra_free_kbytes：系統保留給應用的free記憶體。

這個值決定了/proc/zoneinfo中Normal zone的low值。當系統free記憶體小於vm.min_free_kbytes + vm.extra_free_kbytes 時，kswapd會開始回收記憶體，直到free記憶體達到 /proc/zoneinfo 中high值才停止回收。

這個額外的vm.extra_free_kbytes就是給應用突發記憶體需求時使用的，避免急需記憶體時發生pgscand或kswapd回收記憶體不及時。

vm.extra_free_kbytes 分配多大合適呢？一般能應對流量高峰時1-2秒記憶體需求就可以了。free記憶體減少後，kswapd程式會在後臺回收記憶體的，一般512M-2G可以滿足要求。

context switch 高

有很多種情況都會導致 context switch。MySQL 中的 mutex 和 RWlock 在獲取不成功後，短暫spin，還不成功，就會發生 context switch，sleep，等待喚醒。

在 MySQL中，mutex 和 RWlock導致的 context switch，一般在show global status,show engine innodb mutex,show engine innodb status,performance_schema等中會體現出來，針對不同的mutex和RWlock等待，可以採取不同的優化措施。

除了MySQL的mutex和RWlock，還發現一種情況，是MySQL外的mutex競爭導致context switch高。

典型症狀：

1. MySQL running 高，但系統 qps、tps 低
2. 系統context switch很高，每秒超過200K
3. 在 MySQL 記憶體查不到mutex和RWlock競爭資訊
4. SYS CPU 高，USER CPU 低
5. 併發執行的SQL中出現timestamp欄位，MySQL的time_zone設定為system

分析

對於使用 timestamp 的場景，MySQL 在訪問 timestamp 欄位時會做時區轉換，當 time_zone 設定為 system 時，MySQL 訪問每一行的 timestamp 欄位時，都會通過 libc 的時區函式，獲取 Linux 設定的時區，在這個函式中會持有mutex，當大量併發SQL需要訪問 timestamp 欄位時，會出現 mutex 競爭。

MySQL 訪問每一行都會做這個時區轉換，轉換完後釋放mutex，所有等待這個 mutex 的執行緒全部喚醒，結果又會只有一個執行緒會成功持有 mutex，其餘又會再次sleep，這樣就會導致 context switch 非常高但 qps 很低，系統吞吐量急劇下降。

解決辦法：設定time_zone=’+8:00’，這樣就不會訪問 Linux 系統時區，直接轉換，避免了mutex問題。

另外，對於spin消耗，MySQL配置變數中的innodb_spin_wait_delay 和 innodb_sync_spin_loops 可以用於微調。

作者介紹
高亞芳 北京理工大學計算機系畢業，IT行業老兵，目前負責資料儲存基礎架構工作，開源愛好者。