總結(jié)導(dǎo)致oracle數(shù)據(jù)庫主機CPUsys%高的一些原因-創(chuàng)新互聯(lián)

今天我分享下簡單總結(jié)導(dǎo)致 oracle 數(shù)據(jù)庫主機 CPU sys% 高的一些原因。

成都創(chuàng)新互聯(lián)專注于郟縣企業(yè)網(wǎng)站建設(shè),自適應(yīng)網(wǎng)站建設(shè),商城網(wǎng)站制作。郟縣網(wǎng)站建設(shè)公司,為郟縣等地區(qū)提供建站服務(wù)。全流程定制網(wǎng)站建設(shè)，專業(yè)設(shè)計，全程項目跟蹤，成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

在日常的數(shù)據(jù)庫運維中，操作系統(tǒng) CPU 使用率一直是我們衡量系統(tǒng)負(fù)載的一個比較貼切的指標(biāo)，例如 USER% 可以更好的反饋數(shù)據(jù)庫對 CPU 的使用情況，進(jìn)而我們再次去數(shù)據(jù)庫中找出導(dǎo)致 CPU 消耗高的源頭， wa% 可以反饋 IO 等待消耗的 CPU 時間百分比，當(dāng) wa 的值高時，可以說明 IO 等待比較嚴(yán)重。

然而，當(dāng) CPU SYS% 異常增高的時候，我們都知道是系統(tǒng)內(nèi)核消耗了大量的 cpu ，但常常是束手無措。在 NGBOSS 的數(shù)據(jù)庫運維中，我們把 CPU SYS% 高的問題拋給了主機側(cè)，而主機工程師的回復(fù)便是 CPU sys% 高是因為 ORACLE 用戶進(jìn)程導(dǎo)致，這往往使問題排查無法繼續(xù)進(jìn)行，因此我稍微總結(jié)下目前所遇到幾點 sys cpu 突然增高原因。

從 time 命令說起：

有時，我們使用 time 命令去測試執(zhí)行某一個命令或某個腳本所消耗的時間，例如， time ps ：

 

可以看到其中的時間，分為 real,user 和 sys, 其中的 user 和 sys 便是指的是 CPU 時間，從 IBM 的 Performance and System Tuning 文檔中看到了關(guān)于 time解釋，其中對于user和sys的解釋如下：

 

CPU 時間分為 user 和 sys 組成。 User 值是程序本身以及任何其調(diào)用的庫的子程序所使用的時間。 sys 值是系統(tǒng)調(diào)用使用的時間由程序調(diào)用（直接或間接）。

 

那么 SYS 部分的 CPU 主要會由哪些操作或是系統(tǒng)調(diào)用產(chǎn)生呢？以下列出了日常運維中相對典型的案例現(xiàn)象以及借鑒他人文章的幾點總結(jié)。

 

1> 大量的登錄連接

例如短時間的連接風(fēng)暴的情況，大量的登錄需要新啟動進(jìn)程導(dǎo)致 CPU SYS 飆高，

監(jiān)聽創(chuàng)建新會話要分配進(jìn)程的，這部分由 CPU sys 承擔(dān)。

      實驗：以下是在虛擬機測試的使用腳本模擬多次登錄，隨著 PROCESS 的增加， cpu sys% 出現(xiàn)較大波動。

 

從上面實驗可以看到，隨著登陸會話的持續(xù)增多， sys 的上漲幅度較大，在我們的日常運維中假如遇到短時間內(nèi) sys cpu 飆高的現(xiàn)象，建議盡快排查是否存在大量的連接涌進(jìn)。

 

2> 大量并發(fā)的 I/O 操作。

一般 I/O 操作不會消耗太多的 CPU ，因為主要的時間消耗會在 I/O 操作的設(shè)備上。比如從磁盤讀文件時，主要的時間在磁盤內(nèi)部的操作上，而消耗的 CPU 時間只占 I/O 操作響應(yīng)時間的一少部分。但在大量的并發(fā)的 I/O 時才可能會使得 SYS CPU 有所增加。

  案例： RMDB1 出現(xiàn) sys cpu 持續(xù)增長到 50% 以上

10 月 20 日下午 16 點左右發(fā)現(xiàn) RMDB1 主機 cpu 異常，其中 sys 增長到 50% 以上。

 

查看當(dāng)時的磁盤情況發(fā)現(xiàn) DISK28 、 27 、 20 、 21 四塊盤異常繁忙，磁盤讀特別高，每塊盤的每秒平均達(dá) 350M 左右。

 

 

從數(shù)據(jù)庫中查其盤主要是 MD 庫，這是個業(yè)務(wù)量較小的庫，與 crm 同在一臺主機上。

 

 

查詢 MD 庫等待事件發(fā)現(xiàn)主要存在 direct path read 等待，這也正是磁盤繁忙的原因。

 

后來確定主要是以下 sql 引起，殺除掉正在執(zhí)行的 sql 會話，固定走錯的執(zhí)行計劃之后數(shù)據(jù)庫 direct path read 等待消失，繁忙的 4 塊磁盤也回歸正常， cpu sys 也下降到正常范圍。

 

 

3> GC 引起的 sys cpu 高

　 GC 是 rac 中節(jié)點的緩存共享，對 CPU 的要求貌似非常高，在日常的運維中，總是發(fā)現(xiàn) RAC 中一旦某個節(jié)點出現(xiàn)性能問題，很容易引起另一節(jié)點出現(xiàn)大量的 GC 等待， GC 主要是對內(nèi)存中的操作。 例如 gc cr multiblock request ，一般情況下都是全表掃描或全索引掃描導(dǎo)致， gc cr multiblock request 會造成 CPU 對內(nèi)存的調(diào)度和管理，會消耗 CPU 時間。

案例： 節(jié)點 1 因高消耗 SQL 引起 gc buffer busy acquire 導(dǎo)致 CPU sys 高

9 月 29 日 11 點左右的 CPU sys   異常增高，分析當(dāng)時的等待， log file sysnc, gc buffer busy acquire 和 latch free 的等待都很高，但是其中 log file sysnc 和 latch free 懷疑是因 cpu 資源緊張引起。

 

而 gc buffer busy acquire 很明顯指向了異常 的語句：

 

查詢語句當(dāng)時執(zhí)行情況， 其一次執(zhí)行時間在 60到120秒不等，其中CPU時間在10到20秒不等，這說明語句在執(zhí)行時，有80%的時間用于等待上，但是語句沒有產(chǎn)生物理讀取，結(jié)合會話的等待事件，我們可以知道80%的時間都消耗在了GC的相關(guān)等待上（GC相關(guān)等待會導(dǎo)致CPU sys使用偏高）。

 

從 awr中 Segments by Global Cache Buffer Busy 可以 看到，表 CS_REC_RECEPTION   上 Global Cache Buffer Busy   占數(shù)據(jù)庫總的 86%。這再次證明了系統(tǒng)的GC等待事件確實是有表xxxxx 上的業(yè)務(wù)語句導(dǎo)致。

 

最終發(fā)現(xiàn) 業(yè)務(wù)表在兩個都有運行，包括查詢和和 DML語句 ， 因此引起了較多的 gc buffer busy acquire 等待。以上分析過程是 ORACLE 原廠工程師給出，并推斷 CPU sys 飆高的原因就是因為 GC 等待。在 9 月 29 日當(dāng)天開發(fā)商規(guī)避掉該 sql 之后情況確實好轉(zhuǎn)，但關(guān)于 GC 等待造成 CPU sys 異常增高的案例很難找到進(jìn)一步佐證，并且在平時遇到 gc 等待高時 cpu sys 并不也一定異常高，并且在之后同一節(jié)點仍出現(xiàn)過 CPU sys 異常的問題，每次伴隨著大量的 I/O 操作，懷疑導(dǎo)致高數(shù)據(jù)庫 CPU sys 異常的原因有多種。

 

除了以上原因還有以下操作系統(tǒng)本身的管理機制導(dǎo)致的原因：

4> 進(jìn)程調(diào)度。

這部分 CPU 的使用，在于操作系統(tǒng)中運行隊列的長短，越長的運行隊列（ run queue ），表明越多的進(jìn)程需要調(diào)度，那么內(nèi)核的負(fù)擔(dān)就越高，但是很多時候往往我們看到的運行隊列高很可能是由于 CPU 利用率高導(dǎo)致的結(jié)果。

 

5> 內(nèi)存管理。

比如應(yīng)用程序向操作系統(tǒng)申請內(nèi)存，操作系統(tǒng)維護(hù)系統(tǒng)可用內(nèi)存等。與 ORACLE 類似，越大的內(nèi)存，越頻繁的內(nèi)存管理操作， CPU 的消耗會越高。

 

6> 其他，包括進(jìn)程間通信、信號量處理、設(shè)備驅(qū)動程序內(nèi)部的一些活動等等。

 

      總結(jié)來說 ， CPU 利用率中的 SYS 部分，指的是操作系統(tǒng)內(nèi)核 (Kernel ）使用的 CPU 部分，也就是運行在內(nèi)核態(tài)的代碼所消耗的 CPU ，最常見的就是系統(tǒng)調(diào)用 (SYS CALL) 時消耗的 CPU ，這部分是有可能來自用戶進(jìn)程的申請而發(fā)起的。

      本次列舉的案例主要還是僅表述了日常的問題現(xiàn)象，而具體的原理仍需學(xué)習(xí)深究。

 

 

名稱欄目：總結(jié)導(dǎo)致oracle數(shù)據(jù)庫主機CPUsys%高的一些原因-創(chuàng)新互聯(lián)
瀏覽地址：http://muchs.cn/article10/dhecdo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站策劃、定制網(wǎng)站、微信小程序、網(wǎng)頁設(shè)計公司、品牌網(wǎng)站制作、網(wǎng)站設(shè)計公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)