高cpu 等待事件 resmgr:cpu quantum

某系统cpu使用率突然非常高。

查看ash报告

主要等待事件是log file sync 和resmgr:cpu quantum。排在第二位的等待事件比较少见。resmgr通常跟资源管理有关，跟量子力学没有关系，跟昆腾硬盘也没关系，通常理解为cpu限额。事件类别是Scheduler，说明与调度相关。

resmgr:cpu quantum事件：
会话正在等待分配一定数量的cpu。
启用资源管理器并限制CPU消耗时
将发生此事件。为减少此等待事件的发生，请增加会话的当前使用者组的CPU分配。

等待时间：会话等待获取CPU数量的时间

当时检查数据库resource_manager_plan参数，不为空。

继续看看sql语句与事件的关系

c3y8dhrghbknj是一条select业务语句。



再结合awr看看

通过db time看到还是负载很高的，本机有24个cpu，64G内存。




awr的top 10事件中看到log file sync的Wait Avg（ms）比较大，通常应该低于4ms，现在平均是220ms



再看看后台等待事件

结合log file paralle write的7ms速度，可以初步判定log file sync的原因了。

看看lgwr的trc文件

写入几十KB的日志，需要约1秒，慢如牛的写入速度加上数据库版本基本上可以下结论了。

看看sql方面
还是那条最繁忙的sql，每次执行1.86秒，有待优化（估计建索引即可）。




总结：
1 高cpu与auto sql tune任务有关，通常应该关闭此任务（待验证）。
2 log file sync 与lgwr运行机制有关，通常设置 _use_adaptive_log_file_sync=false（应该没错）。
3 部分语句待优化（待测试）。

参考：
High "Resmgr:Cpu Quantum" Wait Events In 11g Even When Resource Manager Is Disabled (Doc ID 949033.1)
即
alter system set resource_manager_plan='' scope=both;
select 'execute dbms_scheduler.set_attribute('''||WINDOW_NAME||''',''RESOURCE_PLAN'','''');' sql from DBA_SCHEDULER_WINDOWS;

查看自动任务
select * from DBA_AUTOTASK_WINDOW_CLIENTS;

任务的启动：
BEGIN
DBMS_AUTO_TASK_ADMIN.ENABLE(client_name => 'sql tuning advisor',operation => NULL,window_name => NULL);
END;
/

任务的停止：
BEGIN
DBMS_AUTO_TASK_ADMIN.DISABLE(client_name => 'sql tuning advisor',operation => NULL,window_name => NULL);
END;
/

后记：
经过修改隐含参数后
alter system set "_use_adaptive_log_file_sync"=false;

问题完美解决。