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