CPU资源限制测试

问题场景：oracle生产库一个业务用户在交易时段消耗了服务器100%的CPU资源进而影响了同库内实时的生产业务

需求：

1：测试使用资源计划限制oracle 用户使用的CPU资源

2：并确定当用户使用的CPU资源超出资源计划限制后用户会话及SQL的状态

一：创建资源计划测试

1:创建资源资源组

创建资源资源组：'MAINTENANCE'

begin

dbms_resource_manager.create_pending_area(); --创建pending缓存区

dbms_resource_manager.create_consumer_group( --创建资源(消费)组

consumer_group => 'MAINTENANCE', --指定资源组名

comment => 'MAINTENANCE' --资源组注释，必须声明

);

dbms_resource_manager.submit_pending_area();--提交pending缓存区

end;

/

补充：

pending缓存区类似是资源计划的事务池，修改资源计划相关配置必须先在内存开辟一个pending缓存区，修改后的资源计划配置不会立即生效，只有使用dbms_resource_manager.submit_pending_area();提交缓冲区内的修改后配置才会生效

2: 创建消费者与资源资源组的映射规则

将测试用户cpu_test加入资源资源组'MAINTENANCE':

begin

dbms_resource_manager.create_pending_area();

-- Map 'TEST' user to MAINTENANCE group

--根据会话登录名及运行时属性，将会话映射到指定资源组

dbms_resource_manager.set_consumer_group_mapping(

attribute=>'ORACLE_USER', --修改时的映射属性，这里指使用用户名做映射

value=>'CPU_TEST', --要映射的属性值，这里指的就是需映射的用户名

consumer_group=>'MAINTENANCE'); --用户映射到的资源组

dbms_resource_manager.submit_pending_area();

end;

/

3:授权用户访问资源资源组

begin

dbms_resource_manager.create_pending_area();

dbms_resource_manager_privs.grant_switch_consumer_group(

--该过程授予切换到资源组的权限

grantee_name=>'PUBLIC', --要授予权限的用户或角色名，这里直接设置为公共权限

consumer_group=>'MAINTENANCE', --资源组名

grant_option=>FALSE);--是否允许权限传递

dbms_resource_manager.submit_pending_area();

end;

/

4:设置资源组映射优先级

begin

dbms_resource_manager.create_pending_area();

dbms_resource_manager.set_consumer_group_mapping_pri(

--使用会话的多个属性将会话映射到到资源组，数值越小优先级越高

explicit => 1, --显式映射的优先级

oracle_user => 2, --用户名映射的优先级

client_program => 3, --客户端程序的映射优先级

service_module_action => 4, --应用程序模块名称和动作映射的优先级

service_module => 5, --服务名映射的优先级

module_name_action => 6, --应用程序模块名及动作的映射优先级

module_name => 7,--应用程序模块名映射优先级

service_name => 8, --客户端服务名映射的优先级

client_os_user => 9,--客户端操作系统用户名的优先级

client_machine => 10 );--客户端机器映射的优先级

dbms_resource_manager.submit_pending_area();

end;

/

5. 创建资源计划

设置MAINTENANCE资源组中的用户最多只允许使用10%的CPU资源

begin

dbms_resource_manager.create_pending_area();

dbms_resource_manager.create_plan(-- Create Resource Plan

plan=>'MYPLAN',--资源计划名

comment=>'Plan for data warehouse');--资源计划注释

dbms_resource_manager.create_plan_directive(--创建资源计划指令

plan=>'MYPLAN',--资源计划指令名

group_or_subplan=>'MAINTENANCE',--资源组或子计划的名称

comment=>'allocation for MAINTENANCE', --资源组注释

max_utilization_limit=>10);

--指定使用组或子计划可使用的CPU的最大百分比，取值范围：0~100

--NULL代表不做限制或相当于100

dbms_resource_manager.create_plan_directive(--创建资源计划指令

plan=> 'MYPLAN',

group_or_subplan=> 'other_groups',

--other_groups是oracle自带的资源组，所有用户都属于other_groups资源组

comment=> 'this group is mandatory',

max_utilization_limit => 90);

dbms_resource_manager.submit_pending_area();

end;

/

6. 启用资源计划

alter system set resource_manager_plan='MYPLAN' sid='*';

alter system set resource_limit = true;

7．测试用户调用死循环脚本消耗CPU到限制值

一个死循环脚本，只消耗CPU,不消耗内存，

开4个窗口，执行如下脚本

declare

i number;

j number;

begin

i := 0;

loop

j := sqrt(i);

i := i + 1;

end loop;

end;

/

开4个窗口执行上述死循环脚本时，服务器CPU使用率已经达到10%了

8．继续调用死循环脚本

可以看到，当测试用户再执行一个死循环脚本，服务器CPU使用率仍然是10%,且CPU算力几乎平均的分给了测试用户的5个会话，最开始执行死循环的进程分的CPU稍微要多5%左右。

9．执行select语句

再开一个窗口执行select

看到再开一个窗口执行select操作，oracle会把这10%的CPU使用率分给第5个窗口执行select语句，执行时间较没有限制CPU时要多1秒。

（以select count（*） from test;为例：172794行数据

当CPU空闲时 ，查询时间只需要3.5几秒，不到4秒

而当用户CPU使用率达到10%的限制后，相同数据量的查询却要5.6几秒，
多出1~2秒的查询时间

查看此时的测试用户会话的相关信息：

此时测试用户的6个活动会话等待事件都是"resmgr:cpu quantum"，但是会话都是处于活动状态，且彼此间未发生阻塞。

分析：

经过简单测试，可以发现：

  1：oracle资源计划特性的确可以限制指定用户使用的CPU资源总量
  2：当指定用户使用的CPU消耗量达到资源计划限制的值后，不会影响该用户后续会话的登录
  3：如果CPU消耗已达限制值，CPU算力将会按特定算法均分给该用户下的所有活动会话

 （比如限制10%CPU，用户有5个活动会话，这5个活动会话被分配的CPU使用率大概在2%左右）
补充：根据相关资料，这种均分其实可以按某些指标来选择， 比如最长执行时间的会话多分配，预估消耗资源最小会话先分配等，这些场景暂未在此次测试验证
  资源计划的限制值是按服务器CPU算力来限制的，并不能限制指定用户只使用多少个CPU
  4：当用户的CPU消耗超过限制值后，用户下的会话等待事件均为“resmgr:cpu quantum”，但用户会话之间没有阻塞，所有会话都处于活动状态
  5：由于资源限制，当用户消耗资源达到限制值后，相关的SQL执行耗时肯定比未做限制时要高
   （比如：相同数据量的表：未做限制或CPU消耗不高时，做一次COUNT(*)只需要3~4秒，而用户CPU消耗达到10%后，再执行相同的SQL，耗时就需要5~6S)

二：其他用户可消耗的CPU资源

使用未限制用户调用死循环脚本

cat dead_loop.sh

sqlplus test_conn/qwerty_123456@ora11g <<EOF

@dead_loop.sql

exit

eof

使用test_conn（未做限制）用户调用死循环脚本

cat dead_loop.sql

declare

i number;

j number;

begin

i := 0;

loop

j := sqrt(i);

i := i + 1;

end loop;

end;

/

后台多次调用"dead_loop.sh"脚本使用未做CPU限制的用户TEST_CONN调用死循环脚本，观察test_con用户可消耗的最高CPU也只有90%

使用TEST_CONN测试用户调用了35次死循环脚本，消耗服务器CPU使用率到90%,当前除TEST_CONN用户外无其他用户活动会话。

再使用test_conn用户调用两次死循环脚本

test_conn测试用户会话数从35上升到37,操作系统活动进程也上升到37个，但是服务器CPU并未上升，观察一段时间CPU使用率始终在90%左右，后续再调用死循环脚本TEST_CONN用户会话消耗的CPU也都维持在90%左右。

分析：

由于之前在资源计划中对other_groups资源组下用户只分配了90%的CPU，再根据上述测试可以判断，除CPU_TEST用户加入了资源组"MAINTENANCE"组只能使用10%的CPU外，剩余用户都属于OTHER_GROUPS资源组,剩余用户一起使用这90%的CPU。

三：调整其他资源组CPU限制

1：修改资源计划指令

修改前查看当前资源计划指令：

select plan,GROUP_OR_SUBPLAN,TYPE,MAX_UTILIZATION_LIMIT from DBA_RSRC_PLAN_DIRECTIVES where PLAN='MYPLAN';

可以看到资源计划"MYPLAN"对资源组MAINTENANCE和OTHER_GROUPS的CPU限制（max_utilization_limit）分别是10%和90%。

修改资源计划对资源组other_groups的CPU限制到100%(意味着不做限制):

begin

dbms_resource_manager.create_pending_area();

dbms_resource_manager.update_plan(--更新资源计划

plan=>'MYPLAN',--指定更新的资源计划名

new_comment=>'Plan for data warehouse');--新的资源计划说明

dbms_resource_manager.update_plan_directive(--更新资源计划指令

plan=> 'MYPLAN', --资源计划名

group_or_subplan=> 'other_groups',--指定资源组

new_comment=> 'this group is mandatory',--新的资源计划指令说明

new_max_utilization_limit => 100 ); --将资源计划MYPLAN中对other_groups资源组的CPU限制修改为100

dbms_resource_manager.submit_pending_area();

end;

/

可以看到，资源计划指令修改后资源计划MYPLAN对other_groups资源组的CPU资源限制已调整为100；

2：other_groups资源组用户测试

使用other_groups资源组下用户TEST_CONN调用死循环脚本，观察可消耗的最高CPU资源值

可以看到取消对资源组other_groups的CPU资源限制后，使用该资源组下的用户test_conn调用死循环脚本，可以轻易的把服务器CPU使用率压到90%以上

3：压测过程中调整资源计划限制

测试当用户TEST_CONN已经消耗了90%以上的CPU资源后再修改资源计划指令将OTHER_GROUPS资源组用户CPU消耗限制在90%,观察TEST_CONN消耗CPU是否会立即下降到90%.

服务器CPU已被TEST_CONN用户压到98%

调整other_groups资源组CPU限制

begin

dbms_resource_manager.create_pending_area();

dbms_resource_manager.update_plan(--更新资源计划

plan=>'MYPLAN',--指定更新的资源计划名

new_comment=>'Plan for data warehouse');--新的资源计划说明

dbms_resource_manager.update_plan_directive(--更新资源计划指令

plan=> 'MYPLAN', --资源计划名

group_or_subplan=> 'other_groups',--指定资源组

new_comment=> 'this group is mandatory',--新的资源计划指令说明

new_max_utilization_limit => 50 ); --将资源计划MYPLAN中对other_groups资源组的CPU限制修改为50

dbms_resource_manager.submit_pending_area();

end;

/

观察调整后的CPU服务器使用率：

发现在TEST_CONN用户未做任何更改的情况下修改资源计划指令将other_groups资源组CPU限制调整到50后，服务器CPU立即从98%左右下降到53%,说明资源计划指定的更改是立即生效的。

4：比较null和100指定值时的区别

之前已测试限制other_groups资源组CPU为100%,现在将该组资源限制（max_utilization_limit）更新为null

官方文档已说明max_utilization_limit参数值设定为null和设定为100的效果是一样的。

begin

dbms_resource_manager.create_pending_area();

dbms_resource_manager.update_plan(--更新资源计划

plan=>'MYPLAN',--指定更新的资源计划名

new_comment=>'Plan for data warehouse');--新的资源计划说明

dbms_resource_manager.update_plan_directive(--更新资源计划指令

plan=> 'MYPLAN', --资源计划名

group_or_subplan=> 'other_groups',--指定资源组

new_comment=> 'this group is mandatory',--新的资源计划指令说明

new_max_utilization_limit => null ); --将资源计划MYPLAN中对other_groups资源组的CPU限制修改为null

dbms_resource_manager.submit_pending_area();

end;

/

可以看到，将资源计划指令中的max_utilization_limit参数修改为null后数据库认为资源组other_groups的限制就是100

使用other_groups资源组用户test_conn调用死循环脚本，观察服务器CPU的消耗

从上图中可以看到，将资源计划指令中对other_groups资源组的CPU资源限制值max_utilization_limit参数修改为null与将该值设定为100的效果是一致的。

将限制值修改为null，意思就是不对该资源组的资源做限制，与限制该资源组CPU使用率100%是一样的。

分析：

根据上述测试结果可以看出，资源计划指令可以在在线更改并立即生效。且取消对资源组other_groups的CPU使用限制后，该资源组下用户test_conn可以轻易将CPU使用率压到90以上。

同时资源计划指定中的CPU资源限制max_utilization_limit参数值设定为null和设定为100的效果是一样的

四：CPU耗尽时资源分配策略

1:模拟不同资源组间争用CPU资源

测试不同资源组CPU资源限制之和大于100后，不同资源组同时消耗CPU资源到100%时，资源管理器对CPU资源的分配情况

other_groups资源组CPU限制值:100

'MAINTENANCE'资源组CPU限制值10

使用other_groups资源组下用户TEST_CONN调用死循环脚本，将服务器CPU压到97%左右，

再使用'MAINTENANCE'资源组用户CPU_TEST调用死循环脚本，

观察服务器CPU变化及这个两个资源组之间的CPU消耗

select BEGIN_TIME,END_TIME,CONSUMER_GROUP_NAME,AVG_CPU_UTILIZATION,CPU_DECISIONS_EXCLUSIVE from V$RSRCMGRMETRIC;

--查询数据库资源组一分钟内的资源组资源消耗

可以看到，

20:25~20.26:other_groups资源组已经消耗掉了约97%的CPU资源，

20:26：开始使用'MAINTENANCE'资源组用户调用死循环脚本

20:26~20:27: 'MAINTENANCE'资源组消耗5%，other_groups资源组消耗95%

20:27~20:28: 'MAINTENANCE'资源组消耗10%，other_groups资源组消耗91%

20:28~20:29: 'MAINTENANCE'资源组消耗10%，other_groups资源组消耗91%

20:29~20:30: 'MAINTENANCE'资源组消耗10%，other_groups资源组消耗91%

----这里91%不是精确值，存在一定误差，可能导致资源消耗之和大于100%

分析:

根据上述测试结果不难发现，尽管资源组OTHER_GROUPS的CPU资源限制是100%(既不做限制)且已消耗了97%的CPU资源，但随着'MAINTENANCE'资源组用户开始调用死循环脚本，'MAINTENANCE'资源组消耗的CPU逐渐上升，OTHER_GROUPS的资源组的CPU消耗从97%下降到到91%左右，'MAINTENANCE'资源组的CPU消耗达到了该资源组的CPU限制10%。

这种测试结果可以看出资源管理器的资源分配策略更倾向于资源限制较低的资源组，并不是遵照传统的先到先得的分配策略

五：多个资源组限制

1：创建资源组MAINTENANCE_1，限制该资源组CPU消耗不高于20%

创建资源组MAINTENANCE_1

begin

dbms_resource_manager.create_pending_area(); --创建pending缓存区

dbms_resource_manager.create_consumer_group( --创建资源(消费)组

consumer_group => 'MAINTENANCE_1', --指定资源组名

comment => 'MAINTENANCE for 20' --资源组注释，必须声明

);

dbms_resource_manager.submit_pending_area();--提交pending缓存区

end;

/

映射用户CPU_TEST1到MAINTENANCE_1资源组

begin

dbms_resource_manager.create_pending_area();

-- Map 'CPU_TEST1' user to MAINTENANCE group

--根据会话登录名及运行时属性，将会话映射到指定资源组

dbms_resource_manager.set_consumer_group_mapping(

attribute=>'ORACLE_USER', --修改时的映射属性，这里指使用用户名做映射

value=>'CPU_TEST1', --要映射的属性值，这里指的就是需映射的用户名

consumer_group=>'MAINTENANCE_1'); --用户映射到的资源组

dbms_resource_manager.submit_pending_area();

end;

/

已将用户CPU_TEST1切换到资源组MAINTENANCE_1

授权用户CPU_TEST1访问资源组MAINTENANCE_1

begin

dbms_resource_manager.create_pending_area();

dbms_resource_manager_privs.grant_switch_consumer_group(

--该过程授予切换到资源组的权限

grantee_name=>'PUBLIC', --要授予权限的用户或角色名，这里直接设置为公共权限

consumer_group=>' MAINTENANCE_1', --资源组名

grant_option=>FALSE);--是否允许权限传递

dbms_resource_manager.submit_pending_area();

end;

/

创建针对MAINTENANCE_1的资源计划指令

无需创建新的资源计划:

在资源计划MYPLAN加上限制MAINTENANCE_1资源组的资源计划指令

限制资源组MAINTENANCE_1 CPU资源消耗不高于20%

begin

dbms_resource_manager.create_pending_area();

dbms_resource_manager.update_plan(--更新资源计划

plan=>'MYPLAN',--指定更新的资源计划名

new_comment=>'Plan for data warehouse v3');--新的资源计划说明

dbms_resource_manager.create_plan_directive(--创建资源计划指令

plan=>'MYPLAN',--资源计划指令名

group_or_subplan=>'MAINTENANCE_1',--资源组或子计划的名称

comment=>'allocation for MAINTENANCE_1', --资源组注释

max_utilization_limit=>20);

dbms_resource_manager.submit_pending_area();

end;

/

确定资源组MAINTENANCE_1的CPU资源限制（MAX_UTILIZATION_LIMIT）为20

调用死循环脚本测试

先使用MAINTENANCE_1资源组用户CPU_TEST1调用死循环脚本

看到当前服务器CPU使用率维持在20%左右，全部是资源组MAINTENANCE_1消耗掉的。

不管再使用CPU_TEST1用户调用多少次死循环脚本，cpu使用率始终保持在20%左右，不会上升

再使用CPU_TEST用户调用死循环脚本，观察CPU变化趋势：

CPU_TEST用户死循环脚本上来后，服务器CPU使用率稳定在30%左右

查询数据库资源组1分钟内的资源消耗：

确定资源组MAINTENANCE_1（CPU_TEST1用户）在1分钟内消耗系统20%的CPU

确定资源组MAINTENANCE(CPU_TEST用户)在1分钟内消耗系统10%的CPU

与预期情况一致

分析：

根据上述测试结果：

数据库中存在多个资源组，且多个资源组之间CPU资源限制值之和不大于100的情况下，这些资源组内用户最大可消耗的CPU资源不会大于这些资源限制值之和。

比如：

上列资源组MAINTENANCE_1和资源组MAINTENANCE的CPU资源限制分别是20%和10%

那这两个资源组下用户CPU_TEST1和CPU_TEST的所有会话，可以消耗的CPU资源最大也只能是30%

其中CPU_TEST1可以消耗的最大CPU资源只能是20%，CPU_TEST可消耗的CPU资源最大只能是10%

六：汇总总结

文档中章节及验证内容的关系见下表：

该文档已验证的所有结论如下:

1. 资源计划可以实现对指定用户的CPU资源使用限制
2. CPU限制是按CPU算力限制的，不能按CPU个数限制
3. 限制用户以资源组为单位，资源组内用户会话按oracle算法分配限制内的CPU资源
4. 资源计划只限制指定的资源值，只限制CPU使用率不会影响限制组内用户后续会话的登录
5. 当资源组内用户CPU使用已达限制，该组用户下所有活动会话等待事件均为"resmgr:cpu quantum"
6. 会话等待事件为"resmgr:cpu quantum"，但会话仍在活动，且这些会话间不存在因CPU导致的阻塞
7. 限制用户CPU超限制后，SQL执行效率肯定是受影响
8. 资源计划指令可在线修改且立即生效，之前连接的会话也会收到影响
9. 不同资源组之前的CPU限制值加起来可以超过100，
10. 资源计划指定中的CPU资源限制max_utilization_limit参数值设定为null和设定为100的效果是一样的
11. 服务器CPU使用率耗尽时，资源管理器更倾向于先给资源限制值较小的资源组分配资源，并不是遵照传统的先到先得的分配策略
12. 数据库中可以存在多个资源组，一个资源计划中可以存在多个资源计划指令,一个资源计划指定对应一个资源组
13. 资源组内用户最大可消耗的CPU资源不会大于这些资源限制值之和(所有资源组CPU限制之和不大于100时)

相关资料补充

资源组的相关说明：

资源组是一组具有类似资源需求的用户，一个组可以包含多个用户，同时一个用户也可以同时属于多个组，当属于多个组时可以切换用户激活的是哪个组的权限，这个切换可以手动也可以自动完成。

在创建一个ORACLE实例时,会默认提供了18个使用者组

所有的组可以查询DBA_RSRC_CONSUMER_GROUPS和DBA_USERS这两个视图，一个是查看所有的组信息，一个是查看用户的组信息

查看指定用户所属的资源组：

select USERname, INITIAL_RSRC_CONSUMER_GROUP from dba_users;

可以看到，SYS及SYSTEM用户属于SYS_GROUP资源组，而CPU_TEST用户属于MAINTENANCE资源组，其实用户在DBA_USER中显示的资源组都是DEFAULT_CONSUMER_GROUP。

监控资源计划运行状态

查看资源管理器配置和状态

查看使用者组

使用视图DBA_RSRC_CONSUMER_GROUP_PRIVS 显示授予用户或角色的使用者组。

col grantee for a12

col granted_group for a32

col grant_option for a16

col initial_group for a16

SELECT GRANTEE, GRANTED_GROUP, GRANT_OPTION, INITIAL_GROUP FROM dba_rsrc_consumer_group_privs;

查看资源计划信息

使用DBA_RSRC_PLANS视图显示数据库中定义的所有资源计划。

SELECT plan,status,comments FROM dba_rsrc_plans;

查看会话的当前使用者组

col username for a16

col RESOURCE_CONSUMER_GROUP for a32

SELECT sid,serial#,username,resource_consumer_group FROM v$session;

查看当前活动的计划

col name for a24

col is_top_plan for a16

SELECT name, is_top_plan FROM v$rsrc_plan;

资源管理器相关视图及常用SQL

下面的视图监视资源管理器的配置

-- 查看顶层资源计划

SELECT name, is_top_plan FROM v$rsrc_plan;

-- 查看指定资源计划下的所有资源计划指令限制信息

select plan,GROUP_OR_SUBPLAN,TYPE,MAX_UTILIZATION_LIMIT from DBA_RSRC_PLAN_DIRECTIVES where PLAN='MYPLAN';

-- 监视消耗的资源，包括CPU，I/O 和并行

SELECT name, active_sessions, queue_length,

consumed_cpu_time, cpu_waits, cpu_wait_time

FROM v$rsrc_consumer_group;

-- 监视连接会话的状态

SELECT se.sid sess_id, co.name consumer_group,

se.state, se.consumed_cpu_time cpu_time, se.cpu_wait_time, se.queued_time

FROM v$rsrc_session_info se, v$rsrc_consumer_group co

WHERE se.current_consumer_group_id = co.id

AND co.name <> '_ORACLE_BACKGROUND_GROUP_';

col window_name for a32

SELECT sequence# seq, name plan_name,

to_char(start_time, 'YYYY-MM-DD HH24:MM') start_time,

to_char(end_time, 'YYYY-MM-DD HH24:MM') end_time, window_nameFROM v$rsrc_plan_history;

-- SELECT sequence# seq, name, cpu_wait_time, cpu_waits,

consumed_cpu_time FROM v$rsrc_cons_group_history;

-- 跟踪以毫秒为单位的CPU指标，会话数等资源指标过去一分钟的利用率

SELECT sequence#, consumer_group_name, avg_active_parallel_stmts, avg_queued_parallel_stmts,

avg_active_parallel_servers, avg_queued_parallel_servers, parallel_servers_limitFROM v$rsrcmgrmetric;

-- 跟踪以分钟为单位的CPU指标，会话数等资源指标过去一小时的利用率

select BEGIN_TIME,END_TIME,CONSUMER_GROUP_NAME,AVG_CPU_UTILIZATION,RUNNING_SESSIONS_LIMIT from V$RSRCMGRMETRIC_HISTORY order by BEGIN_TIME;