暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

诊断案例三-如何诊断和解决CPU高度消耗(100%)问题

原创 Eygle 2019-07-24
481

很多时候服务器都可能会经历CPU消耗100%的性能问题,排除系统的异常,这类问题通常都是因为系统中存在性能低下甚至存在错误的SQL语句, 消耗了大量的CPU所致。本节将通过一个案例就如何捕获这样的SQL给出一个通用的方法. 

问题描述:系统CPU高度消耗,系统运行缓慢

操作系统:Sun Solaris8

数据库版本:Oracle9.2.0.3

1. 通过Top命令查看

通过Top工具可以观察到,在进程列表里,存在两个高CPU耗用的Oracle进程,分别消耗了47.77%和40.98%的CPU资源:

$ top
load averages:  1.61,  1.28,  1.25                     HSWAPJSDB             10:50:44
172 processes: 160 sleeping, 1 running, 3 zombie, 6 stopped, 2 on cpu
CPU states:  0.2% idle, 98.5% user,  1.3% kernel,  0.0% iowait,  0.0% swap
Memory: 4.0G real, 1.4G free, 1.9G swap in use, 8.9G swap free
   PID USERNAME THR PR NCE  SIZE   RES STATE   TIME FLTS    CPU COMMAND
 20521 oracle     1 40   0  1.8G  1.7G run     6:37    0 47.77% oracle
 20845 oracle     1 40   0  1.8G  1.7G cpu02   0:41    0 40.98% oracle
 20847 oracle     1 58   0  1.8G  1.7G sleep   0:00    0  0.84% oracle
 20780 oracle     1 48   0  1.8G  1.7G sleep   0:02    0  0.83% oracle
 15828 oracle     1 58   0  1.8G  1.7G sleep   0:58    0  0.53% oracle
20493 oracle     1 58   0  1.8G  1.7G sleep   0:03    0  0.29% oracle
 20887 oracle     1 48   0  1.8G  1.7G sleep   0:00    0  0.13% oracle
 20851 oracle     1 58   0  1.8G  1.7G sleep   0:00    0  0.10% oracle
 20483 oracle     1 48   0  1.8G  1.7G sleep   0:00    0  0.09% oracle

2. 找到存在问题的进程信息

通过PID,使用操作系统工具可以找到这两个有问题的进程。确认这是两个远程连接的用户进程:

$ ps -ef|grep 20521
  oracle 20909 20875  0 10:50:53 pts/10   0:00 grep 20521
  oracle 20521     1 47 10:43:59 ?        6:45 oraclejshs (LOCAL=NO)
$ ps -ef|grep 20845
  oracle 20845     1 44 10:50:00 ?        0:55 oraclejshs (LOCAL=NO)
  oracle 20918 20875  0 10:50:59 pts/10   0:00 grep 20845

3. 捕获存在问题的SQL语句

通过如下getsql.sql脚本,我们可以获取相关SQL语句:

SELECT   /*+ ORDERED */ sql_text FROM v$sqltext a
   WHERE (a.hash_value, a.address) IN (
            SELECT DECODE (sql_hash_value,0, prev_hash_value,sql_hash_value),
                   DECODE (sql_hash_value, 0, prev_sql_addr, sql_address)
              FROM v$session b
             WHERE b.paddr = (SELECT addr FROM v$process c WHERE c.spid = '&pid'))
ORDER BY piece ASC;

注意这里我们涉及了3个视图,并应用其关联进行数据获取。

首先需要输入一个pid,这个pid即process id,也就是在Top或ps中我们看到的PID。

通过pid和v$process.spid相关联我们可以获得Process的相关信息,进而通过v$process.addr和v$session.paddr相关联,我们就可以获得和session相关的所有信息。

再结合v$sqltext,我们即可获得当前session正在执行的SQL语句。通过v$process视图,我们得以把操作系统和数据库关联了起来。

4. 连接数据库,找到问题sql及进程

通过Top中我们观察到的PID,进而应用我的getsql脚本,我们得到以下结果输出.

SQL> @getsql
Enter value for spid: 20521
old  10: where c.spid = '&pid'
new  10: where c.spid = '20521'
SQL_TEXT
----------------------------------------------------------------
select * from (select VC2URL,VC2PVDID,VC2MOBILE,VC2ENCRYPTFLAG,S
ERVICEID,VC2SUB_TYPE,CISORDER,NUMGUID,VC2KEY1, VC2NEEDDISORDER,V
C2PACKFLAG,datopertime from hsv_2cpsync where datopertime<=sysda
te and numguid>70000000000308 order by NUMGUid) where rownum<=20

那么这段代码就是当前正在疯狂消耗CPU的罪魁祸首.

接下来需要进行的工作就是找出这段代码的问题,看是否可以通过优化提高其效率,减少资源消耗.

5. 进一步的跟踪

如果需要进一步的跟踪详细信息,可以通过dbms_system包来进行:

SQL> @getsid
Enter value for spid: 20521
old 3: select addr from v$process where spid = &spid)
new 3: select addr from v$process where spid = 20521)
 
SID SERIAL# USERNAME MACHINE
----------------------------------------------------------------
45 38991 HSUSER_V51 hswapjsptl1.hurray.com.cn
SQL> exec dbms_system.set_sql_trace_in_session(45,38991,true);
PL/SQL procedure successfully completed.

关于dbms_system包的使用,在后面的章节将会有详细的介绍。

 

6.一点说明

很多时候,高CPU消耗都是由于问题SQL导致的,所以找到这些SQL通常也就找到了问题所在,通过优化调整通常就可以解决问题。

但是有时候你可能会发现,这些最消耗CPU的进程是后台进程,这一般是由于异常、BUG或者恢复后的异常导致的,需要具体问题具体分析了.


「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论