在日常的數據庫運維中，操作系統 CPU 使用率一直是我們衡量系統負載的一個比較貼切的指標，例如 USER% 可以更好的反饋數據庫對 CPU 的使用情況，進而我們再次去數據庫中找出導致 CPU 消耗高的源頭， wa% 可以反饋 IO 等待消耗的 CPU 時間百分比，當 wa 的值高時，可以說明 IO等待比較嚴重。
然而，當 CPU SYS% 異常增高的時候，我們都知道是系統內核消耗了大量的 cpu ，但常常是束手無措。在 NGBOSS 的數據庫運維中，我們把CPU SYS% 高的問題拋給了主機側，而主機工程師的回覆便是 CPU sys% 高是因爲 ORACLE 用戶進程導致，這往往使問題排查無法繼續進行，因此我稍微總結下目前所遇到幾點 sys cpu 突然增高原因。
從 time 命令說起：
有時，我們使用 time 命令去測試執行某一個命令或某個腳本所消耗的時間，例如， time ps ：
可以看到其中的時間，分爲 real,user 和 sys, 其中的 user 和 sys 便是指的是 CPU 時間，從 IBM 的 Performance and System Tuning文檔中看到了關於 time解釋，其中對於user和sys的解釋如下：
CPU 時間分爲 user 和 sys 組成。 User 值是程序本身以及任何其調用的庫的子程序所使用的時間。 sys 值是系統調用使用的時間由程序調用（直接或間接）。
那麼 SYS 部分的 CPU 主要會由哪些操作或是系統調用產生呢？以下列出了日常運維中相對典型的案例現象以及借鑑他人文章的幾點總結。
1> 大量的登錄連接
例如短時間的連接風暴的情況，大量的登錄需要新啓動進程導致 CPU SYS 飆高，
監聽創建新會話要分配進程的，這部分由 CPU sys 承擔。
實驗：以下是在虛擬機測試的使用腳本模擬多次登錄，隨着 PROCESS 的增加， cpu sys% 出現較大波動。
從上面實驗可以看到，隨着登陸會話的持續增多， sys 的上漲幅度較大，在我們的日常運維中假如遇到短時間內 sys cpu 飆高的現象，建議儘快排查是否存在大量的連接涌進。
2> 大量併發的 I/O 操作。
一般 I/O 操作不會消耗太多的 CPU ，因爲主要的時間消耗會在 I/O 操作的設備上。比如從磁盤讀文件時，主要的時間在磁盤內部的操作上，而消耗的 CPU 時間只佔 I/O 操作響應時間的一少部分。但在大量的併發的 I/O 時纔可能會使得 SYS CPU 有所增加。
案例： RMDB1 出現 sys cpu 持續增長到 50% 以上
10 月 20 日下午 16 點左右發現 RMDB1 主機 cpu 異常，其中 sys 增長到 50% 以上。
查看當時的磁盤情況發現 DISK28 、 27 、 20 、 21 四塊盤異常繁忙，磁盤讀特別高，每塊盤的每秒平均達 350M 左右。
從數據庫中查其盤主要是 MD 庫，這是個業務量較小的庫，與 crm 同在一臺主機上。
查詢 MD 庫等待事件發現主要存在 direct path read 等待，這也正是磁盤繁忙的原因。
後來確定主要是以下 sql 引起，殺除掉正在執行的 sql 會話，固定走錯的執行計劃之後數據庫 direct path read 等待消失，繁忙的 4 塊磁盤也迴歸正常， cpu sys 也下降到正常範圍。
3> GC 引起的 sys cpu 高
GC 是 rac 中節點的緩存共享，對 CPU 的要求貌似非常高，在日常的運維中，總是發現 RAC 中一旦某個節點出現性能問題，很容易引起另一節點出現大量的 GC 等待， GC 主要是對內存中的操作。 例如 gc cr multiblock request ，一般情況下都是全表掃描或全索引掃描導致， gc cr multiblock request 會造成 CPU 對內存的調度和管理，會消耗 CPU 時間。
案例： 節點 1 因高消耗 SQL 引起 gc buffer busy acquire 導致 CPU sys 高
9 月 29 日 11 點左右的 CPU sys 異常增高，分析當時的等待， log file sysnc, gc buffer busy acquire 和 latch free 的等待都很高，但是其中 log file sysnc 和 latch free 懷疑是因 cpu 資源緊張引起。
而 gc buffer busy acquire 很明顯指向了異常 的語句：
查詢語句當時執行情況， 其一次執行時間在 60到120秒不等，其中CPU時間在10到20秒不等，這說明語句在執行時，有80%的時間用於等待上，但是語句沒有產生物理讀取，結合會話的等待事件，我們可以知道80%的時間都消耗在了GC的相關等待上（GC相關等待會導致CPU sys使用偏高）。
從 awr中 Segments by Global Cache Buffer Busy 可以 看到，表 CS_REC_RECEPTION 上 Global Cache Buffer Busy 佔數據庫總的 86%。這再次證明了系統的GC等待事件確實是有表xxxxx 上的業務語句導致。
最終發現 業務表在兩個都有運行，包括查詢和和 DML語句 ， 因此引起了較多的 gc buffer busy acquire 等待。以上分析過程是 ORACLE 原廠工程師給出，並推斷 CPU sys 飆高的原因就是因爲 GC 等待。在 9 月 29 日當天開發商規避掉該 sql 之後情況確實好轉，但關於 GC 等待造成CPU sys 異常增高的案例很難找到進一步佐證，並且在平時遇到 gc 等待高時 cpu sys 並不也一定異常高，並且在之後同一節點仍出現過 CPU sys 異常的問題，每次伴隨着大量的 I/O 操作，懷疑導致高數據庫 CPU sys 異常的原因有多種。
除了以上原因還有以下操作系統本身的管理機制導致的原因：
4> 進程調度。
這部分 CPU 的使用，在於操作系統中運行隊列的長短，越長的運行隊列（ run queue ），表明越多的進程需要調度，那麼內核的負擔就越高，但是很多時候往往我們看到的運行隊列高很可能是由於 CPU 利用率高導致的結果。
5> 內存管理。
比如應用程序向操作系統申請內存，操作系統維護系統可用內存等。與 ORACLE 類似，越大的內存，越頻繁的內存管理操作， CPU 的消耗會越高。
6> 其他，包括進程間通信、信號量處理、設備驅動程序內部的一些活動等等。
總結來說 ， CPU 利用率中的 SYS 部分，指的是操作系統內核 (Kernel ）使用的 CPU 部分，也就是運行在內核態的代碼所消耗的CPU ，最常見的就是系統調用 (SYS CALL) 時消耗的 CPU ，這部分是有可能來自用戶進程的申請而發起的。
本次列舉的案例主要還是僅表述了日常的問題現象，而具體的原理仍需學習深究。