通过top命令抓取cpu高消耗的sql

简介: top命令在linux环境维护中很实用,虽然功能缺失不够sar那么全面。今天和大家分享一个通过top命令来抓取性能sql的案例。 通过top命令抓取了如下的信息。
top命令在linux环境维护中很实用,虽然功能缺失不够sar那么全面。今天和大家分享一个通过top命令来抓取性能sql的案例。
通过top命令抓取了如下的信息。

pid是3585的进程对应的sql 之前已经确定是性能问题导致的了,所以先放过,可以看看pid是8879的这个进程,出现的不是很“稳定”。
可能通过ash,awr不一定能够及时的抓住这些信息,但是通过及时的分析,可能有时候会得到一想不到的收获。
可以通过v$session,v$process,v$sql来结合查找process对应的sql.
可以看到这个进程是属于一个远程的session(LOCAL=NO),是通过一个batch的服务器上发起的请求。
执行的sql很简单。就是一个简单的查询。初步怀疑就是因为查询走了全表扫描而且那个字段可能没有索引。

为了确认,查看表的结构来看看。可以结合user_tab_cols,user_ind_columns来查看表的属性和索引的信息。这些都是用准备好的脚本来生成的,过滤了一些不必要的信息。
可以看到,索引是存在的,在ext_account_number上,而且是唯一性索引。如果那样的话走全表扫描就有些不合常理了。

如果观察的再仔细些,可以看到ext_account_number那个字段是varchar2(12)的。
为了验证表肯定走了全表扫描,我抓了一个awrsqrpt的报告。内容如下,可以看到的确走了全表扫描。而且buffer gets还挺大,cpu消耗比较高。

到此为止,如果还不没明白的话,我做个简单的测试。

我从表里随机抓取10条记录。
SQL> SELECT balance ,EXT_ACCOUNT_NUMBER from ACCOUNT WHERE rownum                                                                          
BALANCE EXT_ACCOUNT_NUMBER
---------- ------------                                                  
         0 10257832                                                      
    772.81 10260829                                                      
    584.22 10259790                                                      
    329.03 10258781                                                      
      -.39 10263317                                                      
      -.14 10260830                                                      
    496.79 10258782                                                      
         0 10258783                                                      
      -.83 10258785                                                      
      -.91 10259791                                                      
                                                                         
10 rows selected.                                                        
然后来trace一把。看看执行的情况。
可以看到,确实走了全表扫描,没有走索引。可以看到filter部分,对于ext_account_number它是在解析的时候做了类型转换的,从varchar2转为number。
一致性读有12704.

这样问题的根源就很清晰了。再换一个,试试走索引的情况。可以看到,效率有了极大的提升。剩下的问题就是协调来解决了。


目录
相关文章
|
1月前
|
缓存 运维 Linux
Linux系统调优详解(三)——CPU状态查看相关命令
Linux系统调优详解(三)——CPU状态查看相关命令
47 1
|
1月前
|
机器学习/深度学习 缓存 监控
linux查看CPU、内存、网络、磁盘IO命令
`Linux`系统中,使用`top`命令查看CPU状态,要查看CPU详细信息,可利用`cat /proc/cpuinfo`相关命令。`free`命令用于查看内存使用情况。网络相关命令包括`ifconfig`(查看网卡状态)、`ifdown/ifup`(禁用/启用网卡)、`netstat`(列出网络连接,如`-tuln`组合)以及`nslookup`、`ping`、`telnet`、`traceroute`等。磁盘IO方面,`iostat`(如`-k -p ALL`)显示磁盘IO统计,`iotop`(如`-o -d 1`)则用于查看磁盘IO瓶颈。
131 10
|
11天前
|
SQL Oracle 关系型数据库
SQL SELECT TOP, LIMIT, ROWNUM 子句
SQL SELECT TOP, LIMIT, ROWNUM 子句
18 4
|
14天前
|
SQL 关系型数据库 MySQL
SQL SELECT TOP, LIMIT, ROWNUM 子句
SQL SELECT TOP, LIMIT, ROWNUM 子句
23 2
SQL SELECT TOP, LIMIT, ROWNUM 子句
|
20天前
|
SQL Oracle 关系型数据库
SQL SELECT TOP, LIMIT, ROWNUM 子句
SQL SELECT TOP, LIMIT, ROWNUM 子句
25 3
|
25天前
|
SQL 关系型数据库 Java
实时计算 Flink版操作报错之在阿里云DataHub平台上执行SQL查询GitHub新增star仓库Top 3时不显示结果,是什么原因
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
1月前
|
缓存 监控 网络协议
cpu相关指标(top、uptime、vmstat、mpstat、sar、pidstat、ps、dstat、perf、tcpdump、lscpu)等常见使用方法(三)
cpu相关指标(top、uptime、vmstat、mpstat、sar、pidstat、ps、dstat、perf、tcpdump、lscpu)等常见使用方法
|
1月前
|
监控 Unix Linux
cpu相关指标(top、uptime、vmstat、mpstat、sar、pidstat、ps、dstat、perf、tcpdump、lscpu)等常见使用方法(二)
cpu相关指标(top、uptime、vmstat、mpstat、sar、pidstat、ps、dstat、perf、tcpdump、lscpu)等常见使用方法
|
1月前
|
JSON 缓存 监控
cpu相关指标(top、uptime、vmstat、mpstat、sar、pidstat、ps、dstat、perf、tcpdump、lscpu)等常见使用方法(一)
cpu相关指标(top、uptime、vmstat、mpstat、sar、pidstat、ps、dstat、perf、tcpdump、lscpu)等常见使用方法
|
1月前
|
SQL 关系型数据库 分布式数据库
在PolarDB中,如果慢SQL导致了CPU升高,进而又产生了更多的慢SQL
【2月更文挑战第22天】在PolarDB中,如果慢SQL导致了CPU升高,进而又产生了更多的慢SQL
18 1