本篇博客记录一次性能测试过程中,定位对CPU使用率高的瓶颈问题,主要定位SQL为准
一、用SQL命令定位
1.首先用TOP命令监控系统资源,如果是AIX系统,就用topas,进入TOP命令的滚动刷新数据时,发现userCPU高达98%!!
保持top的状态下,按shift+p,可以将所有进程按CPU使用率高低排序,这样可以了解消耗CPU最多的进程是哪些
可以看到,当前userCPU使用率高达98%,且此时TPS不再随并发数上升了,可以认为已经达到性能瓶颈了,且是由CPU瓶颈造成的
2.排序完后,将上图排在第一位的CPU使用率最高的PID记录下来(此处是172928),
①然后进入dba权限的用户,su oracle(也可以用pl_sql进入)
②然后进去sql命令行和dba权限
sqlplus / as sysdba
③现在v$process 视图中找到pid对应的地址addr,将进程号pid和oracle的session联系起来
SQL:select addr from v$process where spid=172928;
(简介:v$process视图包含当前系统oracle运行的所有进程信息。常被用于将oracle或服务进程的操作系统进程ID与数据库session之间建立联系。也就是可以通过进程PID来寻找数据库的session)
④再通过刚才的addr,在v$session表找到对应的sql_id
SQL:select sql_id from v$session where paddr=‘00000003CEA444C8‘;
⑤再通过sql_id可以找到对应的SQL是哪条
SQL:select * from v$sql where sql_id = ‘00000003CEA444C8‘;
实际上,上面是三个SQL可以联表,
SQL如下:
select t3.SQL_TEXT
from v$process t1
inner join v$session t2
on t1.ADDR = t2.PADDR
inner join v$sql t3
on t2.SQL_ID = t3.SQL_ID
where t1.SPID = 172928(这个pid就是进程id);
用命令行得到的结果如下:
用PL_sql得到如下结果:
到这里既已经定位出占用CPU高的SQL之一的,在可以结合业务场景和SQL的效率,以及和开发人员/DBA等沟通是否优化或如何优化
(顺便此处提示,数据库中不同的数据量会对性能差距影响很大,本次测试中,10W的数据量和20W的数据量,TPS相差达到一倍!!)
二、用AWR报告定位CPU高的SQL
AWR报告如何导出,可以见本人此篇博客内容
导出AWR报告之后,
①在main report的SQL statistics中,点击开,结果如下:
②进入SQL的统计中,看到下面这个结果
③点击SQL ordered by CPU Time
在total这行可以看到累计消耗CPU最高的SQL,
④点击SQL的id,即可看到完整的SQL结果,如下述:
5.点开以后,可以看到的SQL如下所示,这个两个就是占用CPU高的SQL原因,再结合着业务场景以及沟通,看看是否优化吧~~~~
原文:http://www.cnblogs.com/life-for-test/p/6840314.html