Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2667253
  • 博文数量: 570
  • 博客积分: 1860
  • 博客等级: 上尉
  • 技术积分: 6259
  • 用 户 组: 普通用户
  • 注册时间: 2008-04-07 08:51
个人简介

偶尔有空上来看看

文章分类

全部博文(570)

文章存档

2022年(64)

2021年(238)

2020年(115)

2019年(11)

2018年(9)

2017年(9)

2016年(17)

2015年(7)

2014年(4)

2013年(1)

2012年(11)

2011年(27)

2010年(35)

2009年(11)

2008年(11)

分类: Oracle

2021-03-31 06:38:28

某系统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;

问题完美解决。

阅读(1115) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~