總結導致oracle資料庫主機CPU sys%高的一些原因

今天我分享下簡單總結導致 oracle 資料庫主機 CPU sys% 高的一些原因。

在日常的資料庫運維中，作業系統 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 ，這部分是有可能來自使用者程式的申請而發起的。

      本次列舉的案例主要還是僅表述了日常的問題現象，而具體的原理仍需學習深究。

 

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29863023/viewspace-2199598/，如需轉載，請註明出處，否則將追究法律責任。