溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》

一個(gè)RESOURCE MANAGER引起的問題分析

發(fā)布時(shí)間：2020-08-11 19:46:42 來源：ITPUB博客 閱讀：423 作者：darren__chan 欄目：關(guān)系型數(shù)據(jù)庫(kù)



1.分析hanganalyze日志：

Chains most likely to have caused   the hang: 《《《最 終 阻塞源都是由于 resmgr:cpu quantum 引起。

 [a] Chain 1 Signature: ' resmgr:cpu quantum '<='buffer busy   waits'<='buffer busy waits'<='enq: TX - index contention'

     Chain 1 Signature Hash: 0xe7466825

 [b] Chain 2 Signature: ' resmgr:cpu quantum '<='buffer busy waits'

     Chain 2 Signature Hash: 0x23972dee

 [c] Chain 3 Signature: ' resmgr:cpu quantum '<='buffer busy waits'

     Chain 3 Signature Hash: 0x23972dee

====================================================================

Chain   1:

-------------------------------------------------------------------------------

    Oracle session identified by:

    {

                instance: 1 (jfdb.jfdb1)

                   os id: 78941

              process id: 1240, oracle@XXX-JF-DB03

              session   id: 22 <<<< session 22

        session serial #: 32445

    }

    is waiting for 'enq: TX - index   contention' with wait info:

    {

                      p1:   'name|mode'=0x54580004

                      p2: 'usn<<16 |   slot'=0x1cb0015

                      p3: 'sequence'=0xf3fa7

            time in wait: 0.122389 sec

           timeout after: never

                 wait id: 199367

                blocking: 0 sessions

            wait history:

              * time between current wait and   wait #1: 0.000318 sec

             ………

    }

and is blocked by <<<< 被阻塞

 => Oracle session identified by:

{

                instance: 1 (jfdb.jfdb1)

                   os id: 1349

process   id: 2756, oracle@XXX-JF-DB03

session id: 3320 <<<<session 3320

        session serial #: 3849

}

which   is waiting for ‘buffer busy waits’ with wait info:

{

p1:   ‘file#’=0x8c

p2:   ‘block#’=0x286540

p3:   ‘class#’=0x1

time   in wait: 0.218850 sec

           timeout after: never

                 wait id: 51286

                blocking: 58 sessions

wait   history:

 ……….

}

     and is blocked by <<<< 被阻塞

 => Oracle session identified by:

    {

                instance: 1 (jfdb.jfdb1)

                   os id: 3182

              process id: 2975, oracle@XXX-JF-DB03

              session   id: 5658 <<<session 5658

        session serial #: 181

    }

    which is waiting for 'buffer busy waits'   with wait info:

    {

                      p1: 'file#'=0x8c

                      p2: 'block#'=0x285b1f

                      p3: 'class#'=0x1

            time in wait: 0.219271 sec

           timeout after: never

                 wait id: 38737

                blocking: 63 sessions

            wait history:

              。。。。。。

    }

    and is blocked by<<<< 被阻塞

 => Oracle session identified by:

    {

                instance: 1 (jfdb.jfdb1)

                   os id: 27602

              process id: 2384, oracle@XXX-JF-DB03

              session id: 334   《《《session 334

        session serial #: 757

    }

    which is waiting for 'resmgr:cpu quantum'   with wait info:

    {

                      p1: 'location'=0x2

                      p2: 'consumer group   id'=0x3259

                      p3: ' '=0x0

            time in wait: 0.040860 sec

           timeout after: never

                 wait id: 95941

                blocking: 114 sessions

            wait history:

            。。。。。。。

    }

 

Chain   1 Signature: 'resmgr:cpu quantum'<='buffer busy waits'<='buffer busy   waits'<='enq: TX - index contention'

Chain   1 Signature Hash: 0xe7466825

 

對(duì) 以上 hanganalyze 會(huì) 話進(jìn) 行整理：

session : 334

同 時(shí) 阻塞114個(gè)會(huì) 話

阻塞了》

session : 5658

同 時(shí) 阻塞63個(gè)會(huì) 話

阻塞了》

session : 3320

同 時(shí) 阻塞 58 個(gè)會(huì) 話

阻塞了》

session id: 22

resmgr:cpu quantum

buffer busy waits

buffer busy waits

enq: TX - index contention

 

從以上 hanganalyze 日志可以看出， enq: TX - index contention 和 buffer busy waits 的等待堆積最終的源頭是由于 resmgr:cpu quantum 等待引起，并且這些等待同時(shí)又阻塞了多個(gè)其他會(huì)話。

2.關(guān)于resmgr:cpu quantum等待事件解釋：

以下從文檔 ID 2097889.1 可以獲得該等待事件的說明：

《 WAITEVENT: "resmgr:cpu quantum" Reference   Note ( 文檔 ID 2097889.1) 》

·   Event   'resmgr: cpu quantum' is a standard event used by resource manager to control the allocation of   CPU to processes .   When a session waits for 'resmgr: cpu quantum' that session is waiting to be   allocated a quantum of CPU time.

等待事件 'resmgr ： cpu quantum' 是 資源管理器用來控制 CPU 分配給進(jìn)程 的標(biāo)準(zhǔn)事件。   當(dāng)會(huì)話等待 'resmgr ： cpu quantum' 時(shí)， 會(huì)話正在等待分配一個(gè) CPU 時(shí)間額度 。

This wait occurs when the resource   manager is enabled and is throttling CPU consumption. To reduce the   occurrence of this wait event, increase the CPU allocation for the session's   current consumer   group .

當(dāng)啟用資源管理器并限制 CPU 消耗時(shí)會(huì)發(fā)生此等待。 為了減少此等待事件的發(fā)生，請(qǐng)?jiān)黾訒?huì)話當(dāng)前消費(fèi)組的 CPU 分配 。

一個(gè)RESOURCE MANAGER引起的問題分析

      該等待事件存在的意義是當(dāng)resource manager控制CPU調(diào)度時(shí)，需要控制對(duì)應(yīng)進(jìn)程暫時(shí)不使用CPU而進(jìn)程到內(nèi)部運(yùn)行隊(duì)列中，以保證該進(jìn)程對(duì)應(yīng)的consumer group(消費(fèi)組)沒有消耗比指定resource manager指令更多的CPU。此時(shí)session就會(huì)以” resmgr:cpu quantum ”的名義等待在內(nèi)部運(yùn)行隊(duì)列中，wait一段時(shí)間以減少對(duì)CPU的爭(zhēng)用，直到再次獲得CPU時(shí)該等待事件結(jié)束。

3.分析為何會(huì)出現(xiàn)資源管理：

《 11g: Scheduler Maintenance Tasks or Autotasks ( 文檔 ID 756734.1) 》

一個(gè)RESOURCE MANAGER引起的問題分析

 

      根據(jù)以上說明，可以發(fā)現(xiàn)在 Oracle 11g 中，在默認(rèn)情況下會(huì)啟用自動(dòng)化維護(hù)任務(wù)，數(shù)據(jù)庫(kù)會(huì)在工作日的每晚 22:00 到第二天的凌晨 2:00 ，周末的凌晨 6:00 到第二天的凌晨 2:00, 自動(dòng)開啟自動(dòng)化維護(hù)窗口對(duì)數(shù)據(jù)庫(kù)進(jìn)行諸如優(yōu)化器的統(tǒng)計(jì)信息收集、自動(dòng) SQL 的優(yōu)化。在此期間數(shù)據(jù)庫(kù)中便由 resource manager 來控制 CPU 的調(diào)度，啟用資源管理計(jì)劃主要是為了保障維護(hù)窗口內(nèi)的任務(wù)有充分的資源進(jìn)行使用。

      從告警日志中可以看出， 4 月 1 日 6:00 啟動(dòng)自動(dòng)化維護(hù)窗口的信息：

Current log# 6 seq# 23750 mem# 0: +DG_DATA/jfdb/onlinelog/group_6.279.909112437

Sun Apr 01 05:51:29 2018

Archived Log entry 46019 added for thread   1 sequence 23749 ID 0x4d5ab97e dest 1:

Sun Apr 01 06:00:00 2018 《《《《 6 點(diǎn)整開啟自動(dòng)化維護(hù)窗口

Setting Resource Manager plan   SCHEDULER[0x32DF]:DEFAULT_MAINTENANCE_PLAN via scheduler window

Setting Resource Manager plan   DEFAULT_MAINTENANCE_PLAN via parameter

Sun Apr 01 06:00:00 2018

Starting background process   VKRM 《《《啟動(dòng)相應(yīng)的進(jìn)程

Sun Apr 01 06:00:00 2018

VKRM started with pid=361, OS id=48797

     

那么資源管理計(jì)劃是如何限制資源的呢？ 需要了解 RESOURCE MANAGER 的機(jī)制。

 

4.關(guān)于RESOURCE MANAGER的機(jī)制：

    Oracle 開啟自動(dòng)維護(hù)任務(wù)是使用的資源管理計(jì)劃是 DEFAULT_MAINTENANCE_PLAN ， 這 個(gè) 資 源管理 計(jì) 劃控制CPU方法是使用是默 認(rèn) EMPHASIS 法， 這 種方法是多 級(jí)計(jì) 劃，它以百分比形式指定CPU 如何在使用者 組 之 間 分布。CPU 占用率的分配 級(jí)別為 從1 到8， 級(jí)別 1  的 優(yōu) 先 級(jí) 最高，將CPU  資 源在 給 定 級(jí)別 按指定的百分比分配，把 給 定 級(jí)別 上沒有使用的使用者 資 源可供下一 級(jí)別 的使用者 組 使用。在當(dāng)前數(shù)據(jù) 庫(kù) 中DEFAULT_MAINTENANCE_PLAN的 資 源管理 計(jì) 劃只用到了2個(gè) 級(jí)別 。

    在oracle 11g中， 實(shí)際 上CPU_P*的參數(shù)已 經(jīng) 是失效了，而 應(yīng)該 是MGMT_P*的參數(shù)，所以我 們 之前參考的是舊的參數(shù),但 實(shí)際 是同 樣 效果。


一個(gè)RESOURCE MANAGER引起的問題分析

一個(gè)RESOURCE MANAGER引起的問題分析

以下當(dāng)前資源管理計(jì)劃所使用 MGMT_P* 的 情況：

一個(gè)RESOURCE MANAGER引起的問題分析

    在 這 個(gè) 資 源管理 計(jì) 劃DEFAULT_MAINTENANCE_PLAN中，主要存在四個(gè)CPU使用 組 ： 1. ORA$AUTOTASK_SUB_PLAN 和 ORA$DIAGNOSTICS 實(shí)際 是用于自 動(dòng)維護(hù) 任 務(wù)的。

2. SYS_GROUP 是 SYS 和 SYSTEM 用 戶 的初始使用者 組，組中的會(huì)話都是 sys 或 system 賬號(hào)創(chuàng)建的會(huì)話。

3. OTHER_GROUPS 用于在活 動(dòng)資 源 計(jì) 劃之外的所有使用者 組擁 有的會(huì) 話，即使其他業(yè)務(wù)用戶及個(gè)人用戶的會(huì)話。

    資 源管理 計(jì) 劃中MGMT_P* 設(shè) 置的百分比 值 并不是一個(gè)固定限制的 值 是一個(gè)在 資 源 緊張時(shí) 的限制 值 ，但在 資 源空 閑時(shí) 有可能超出 這 個(gè) 值 。

    例如，在DEFAULT_MAINTENANCE_PLAN中ORA$AUTOTASK_SUB_PLAN分配了25%，但此 時(shí) 如果數(shù)據(jù) 庫(kù) 比 較 空 閑 ，SYS_GROUP和OTHER_GROUPS等其他 組 沒有什么 資 源占用，ORA$AUTOTASK_SUB_PLAN 則 可能增 長(zhǎng) 到50%，但如果此 時(shí)資 源比 較緊張 OTHER_GROUPS 且已 經(jīng) 占用50%以上，ORA$AUTOTASK_SUB_PLAN 則 需下降到25%。

    因此，在 這 個(gè) 資 源管理 計(jì) 劃中，ORA$AUTOTASK_SUB_PLAN和ORA$DIAGNOSTICS 設(shè) 了MAX_UTILIZATION_LIMIT最大使用限制 為 90 。 這樣 即使cpu是空 閑 的， 該組 或 計(jì) 劃也不能分配90%以上的cpu 資 源。

對(duì) 于 資 源 計(jì) 劃而言， 為 某個(gè)消耗 組 或者子 計(jì) 劃分配的份 額 若沒有使用，就可以被其他的消耗 組 或子 計(jì) 劃使用。

 

再次分析 這 個(gè) 資 源管理 計(jì) 劃DEFAULT_MAINTENANCE_PLAN，SYS_GROUP 優(yōu) 先 級(jí) 最高在 級(jí)別 1 ，分配75%，在當(dāng) 時(shí) 的情況，sys或system 賬 號(hào) 創(chuàng) 建的會(huì) 話 占用的CPU 資 源并不一定達(dá)到了75%，其剩余的 資 源 則 分配 給級(jí)別 2 。在 級(jí)別 2 中ORA$AUTOTASK_SUB_PLAN和ORA$DIAGNOSTICS的自 動(dòng)維護(hù) 任 務(wù) 在 資 源 緊張 的情況下用了30%，而其余70% 則 分配 給 了OTHER_GROUPS的 業(yè)務(wù) 會(huì) 話 。

資 源管理 計(jì) 劃中MGMT_P* 設(shè) 置的百分比 值 可以理解 為 依據(jù)CPU個(gè)數(shù)的百分比來 計(jì) 算， 這 CPU 個(gè)數(shù) 則 來自CPU_COUNT參數(shù) 設(shè) 置的 值 。


一個(gè)RESOURCE MANAGER引起的問題分析
5.發(fā)現(xiàn)CPU_COUNT參數(shù)異常：

    在排查的過程中，發(fā)現(xiàn)當(dāng)前數(shù)據(jù)庫(kù)的CPU_COUNT僅設(shè)置為8，而實(shí)際上這臺(tái)主機(jī)有32個(gè)CPU 核數(shù)，64個(gè)邏輯CPU。

CPU_COUNT:

一個(gè)RESOURCE MANAGER引起的問題分析

實(shí)際CPU Cores及邏輯cpu個(gè)數(shù)：

一個(gè)RESOURCE MANAGER引起的問題分析

在oracle 官方文檔中已說明CPU_COUNT是依據(jù)CPU cores 的數(shù)量來指定的，并且也說明很多組件包括Resource Manager都是依靠這個(gè)cpu個(gè)數(shù)的。 一個(gè)RESOURCE MANAGER引起的問題分析

一個(gè)RESOURCE MANAGER引起的問題分析

這說明了，在資源管理計(jì)劃開啟時(shí)，受CPU_COUNT 為8的限制，數(shù)據(jù)庫(kù)只能使用到了主機(jī) 32個(gè)CPU 核數(shù)中的8個(gè)，即為1/4。

分析故障期間主機(jī)的CPU 使用情況，發(fā)現(xiàn)在資源管理計(jì)劃開啟后，CPU使用率逐漸升高，但始終不超過25%，直到9:30后手工禁用了資源管理計(jì)劃，CPU資源被放開，CPU使用率則立即上升到45%左右。



     因此，可以看出，資 源管理 計(jì) 劃 打開期間，由于CPU_COUNT的設(shè)置過小，導(dǎo)致了數(shù)據(jù)庫(kù)只能最多使用到了主機(jī)25%的CPU資源，并且受以上資源管理計(jì)劃控制CPU機(jī)制的影響，業(yè)務(wù)會(huì)話可能只能用到這25% CPU資源中的70%，這就是導(dǎo)致數(shù)據(jù)庫(kù)在4月1日高峰期時(shí)數(shù)據(jù)庫(kù)達(dá)到了CPU了資源瓶頸的原因。

 



向AI問一下細(xì)節(jié)

免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI
助
手