某系统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;
问题完美解决。
阅读(5244) | 评论(0) | 转发(0) |