个人简介
偶尔有空上来看看
文章分类
文章存档
最近访客
相关博文
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
分类： 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;
问题完美解决。
查看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;
问题完美解决。
给主人留下些什么吧！~~