一次数据库响应慢的问题诊断

简介: 今天接到开发一个同事的电话,说前端系统那边反馈有一个查询很慢,初步怀疑是有一些并发或者锁之类的问题导致的。 接到问题之后,自己还是带着一些的紧迫感来处理的。 首先查看资源使用情况,使用top来检查,结果发现CPU使用率也不高,都在90%以上的idle 查看数据库的DB time情况,发现数据库的负载其实不高,但是还是有所提高,需要进一步关注。
今天接到开发一个同事的电话,说前端系统那边反馈有一个查询很慢,初步怀疑是有一些并发或者锁之类的问题导致的。
接到问题之后,自己还是带着一些的紧迫感来处理的。
首先查看资源使用情况,使用top来检查,结果发现CPU使用率也不高,都在90%以上的idle
查看数据库的DB time情况,发现数据库的负载其实不高,但是还是有所提高,需要进一步关注。

查看锁等待情况,也没有任何的事务和锁等待。
查看session的使用情况发现并发量其实很低,TPS的值非常低。

为了进一步验证,抓取了近几个小时的日志归档情况和redo的生成量情况,发现归档基本就是1个小时1次,所以暂时也没有发现异常的活动。
这就有些奇怪了。session使用率不高,并发不高,CPU使用率也不高,没有锁等待,redo生成量也不高,到底是怎么回事呢。
进一步和开发同时进行沟通,他们反馈说在前端的页面查询会触发一个表的查询,那个表其实也不大,而且在查询中还是使用索引列的,所以查询应该不会有什么问题。
但是点击查询的时候就会一直卡在那儿。所以想让我们来看看到底数据库层面发生了什么。
首先肯定告诉她的是,数据库的负载和使用率其实并不高,而且并发事务和session使用率也很低,可以基本排除是并发和数据库负载导致的问题。
过了几分钟之后,开发给我的反馈是查询有结果了,但是又过了几分钟,又反馈说查询又没有反应了。
这种情况下,再次查看资源的使用情况和原来一样,但是他们也想知道可能是什么原因导致的问题,
看来常规的思路还是不够快准狠,我们来试试ash快速查询。
SELECT /* use_hash(sess,proc,undo,tmp) use_nl(s)*/ distinct
        sess.inst_id,
        sess.sid,
        sess.serial#,
        sess.username,
        substr(osuser,1,10) osuser,
        status,
        sess.process,
        proc.spid,
        sess.machine,
        sess.program,
        regexp_substr(NUMTODSINTERVAL(nvl((SYSDATE-SQL_EXEC_START)*24*60*60,last_call_et), 'SECOND'),'+\d{2} \d{2}:\d{2}:\d{2}') running_sec,
        TEMP_MB, UNDO_MB,
        s.sql_id ,
        TSPS.NAME TSPS,
        decode(sess.action,null,'',sess.action||', ')||replace(s.sql_text,chr(13),' ') sql
FROM
        gv$session sess,
        gv$process proc,
        gv$sql s,
        (select ses_addr as saddr,sum(used_ublk/128) UNDO_MB from v\$transaction group by ses_addr) undo,
        (select session_addr as saddr, SESSION_NUM serial#, sum((blocks/128)) TEMP_MB from gv$sort_usage group by  session_addr, SESSION_NUM) tmp,
        (select inst_id,sid,serial#,event,t.name from gv$session ls, sys.file$ f, sys.ts$ t where status='ACTIVE' and ls.p1text in ('file number','file#') and ls.p1=f.file#  and f.ts#=t.ts#) tsps
WHERE sess.inst_id=proc.inst_id (+)  
and   sess.saddr=tmp.saddr (+) and sess.serial#=tmp.serial# (+)
AND   sess.status='ACTIVE' and sess.username is not null
and   sess.sid=tsps.sid (+) and sess.inst_id=tsps.inst_id(+) and sess.serial#=tsps.serial#(+)
AND   sess.paddr=proc.addr (+)
and   sess.sql_id = s.sql_id (+)
and   sess.saddr=undo.saddr (+)
ORDER BY running_sec desc,4,1,2,3

通过这个语句能够查看到当前数据库中的active session的情况,但是有些遗憾的是只发现了两个active session都在进行有些相似的多表关联查询。
当然这个select语句常理是不会阻塞另外一个select语句的,所以也就没有太多的关注,但是和开发人员反反复复排查了几次,发现的规律就是那个查询完成之后,得到的反馈是前端的页面查询马上就正常了。

这个时候不得不怀疑是这个查询语句的影响了。数据库负载很低,也不至于一个查询语句就会这么影响全局吧。我也这个发现和开发同事做了反馈,他们也认为应该没有关系。但是逐步的分析,我发现如果这个查询会阻塞另外一个查询,那么只有一个原因,那就是前端的触发的那个select一定是在等待这个复杂的select完成才会触发。它们应该是在一个类似事务的流程之内。如果说是一个事务还是不严谨的,如果是事务,问题就好办了,我们可以通过闪回事务来印证他们是在一个事务的,这个地方实在是无能为力。
为了验证这个想法,我把复杂查询对应的用户名,os用户,客户端machine等等明细的信息进行了整理,发现和开发反馈的时间点基本是吻合的,而且它们是从同一个客户端触发的,远程的machine名都是同一个,上下文环境很相似,所以通过这个也可以佐证我的想法了,对于这个问题的进一步分析,为什么那个查询会持续那么长时间,抓取了对应的执行计划,发现相关的几个大表都走了全表扫描。
-------------------------------------------------------------------------------
| Id  | Operation                        | Name                | Rows  | Bytes 
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                     |       |       
|   1 |  HASH GROUP BY                   |                     |     1 |   332 
|*  2 |   HASH JOIN                      |                     |     1 |   332 
|   3 |    NESTED LOOPS OUTER            |                     |     1 |   300 
|   4 |     NESTED LOOPS                 |                     |     1 |   192 
|   5 |      NESTED LOOPS                |                     |     1 |   174 
|   6 |       TABLE ACCESS FULL          | M_POOL_TEST         |  2420 | 67760 
|*  7 |       TABLE ACCESS BY INDEX ROWID| TES_BASE            |     1 |   146 
|*  8 |        INDEX RANGE SCAN          | IND_TES_BASE_AK     |     1 |       
|*  9 |      TABLE ACCESS BY INDEX ROWID | M_TEST_APP          |     1 |    18 
|* 10 |       INDEX UNIQUE SCAN          | PK_M_TEST_APP       |     1 |       
|* 11 |     TABLE ACCESS BY INDEX ROWID  | TES_EXTEND          |     1 |   108 
|* 12 |      INDEX RANGE SCAN            | IND_TES_EXTEND_RID  |     1 |       
|  13 |    TABLE ACCESS FULL             | M_POOL_TEST_CHANNEL |   398 | 12736 

所以后续的分析就是来看看这个查询是否是新增的需求,为什么之前没有碰到这个问题,这两个全表扫描的表都是大表,所以查询时间自然少不了。
可以进一步来分析为什么走了全表扫描,怎么尝试来优化sql了。
所以数据库负载低,资源使用率低,照样也可能造成响应慢的问题,都需要DBA进行关注。

目录
相关文章
|
6月前
|
Prometheus 网络协议 JavaScript
api 网关 kong 数据库记录请求响应报文
Kong的tcp-log-with-body插件是一个高效的工具,它能够转发Kong处理的请求和响应。这个插件非常适用于需要详细记录API请求和响应信息的情景,尤其是在调试和排查问题时。
175 0
api 网关 kong 数据库记录请求响应报文
|
1天前
|
监控 关系型数据库 MySQL
如何监控和诊断 MySQL 数据库的性能问题?
【10月更文挑战第28天】监控和诊断MySQL数据库的性能问题是确保数据库高效稳定运行的关键
6 1
|
16天前
|
缓存 弹性计算 NoSQL
新一期陪跑班开课啦!阿里云专家手把手带你体验高并发下利用云数据库缓存实现极速响应
新一期陪跑班开课啦!阿里云专家手把手带你体验高并发下利用云数据库缓存实现极速响应
|
3月前
|
存储 消息中间件 人工智能
AI大模型独角兽 MiniMax 基于阿里云数据库 SelectDB 版内核 Apache Doris 升级日志系统,PB 数据秒级查询响应
早期 MiniMax 基于 Grafana Loki 构建了日志系统,在资源消耗、写入性能及系统稳定性上都面临巨大的挑战。为此 MiniMax 开始寻找全新的日志系统方案,并基于阿里云数据库 SelectDB 版内核 Apache Doris 升级了日志系统,新系统已接入 MiniMax 内部所有业务线日志数据,数据规模为 PB 级, 整体可用性达到 99.9% 以上,10 亿级日志数据的检索速度可实现秒级响应。
AI大模型独角兽 MiniMax 基于阿里云数据库 SelectDB 版内核 Apache Doris 升级日志系统,PB 数据秒级查询响应
|
3月前
|
Java XML Maven
跨越时代的飞跃:Struts 2 升级秘籍——从旧版本无缝迁移到最新版,焕发应用新生!
【8月更文挑战第31天】随着软件技术的发展,Struts 2 框架也在不断更新。本文通过具体案例指导开发者如何从旧版平滑升级到 Struts 2.6.x。首先更新 `pom.xml` 中的依赖版本,并执行 `mvn clean install`。接着检查 `struts.xml` 配置,确保符合新版本要求,调整包扫描器等设置。审查 Action 类及其注解,检查配置文件中的弃用项及插件。更新自定义拦截器实现,并验证日志配置。最后,通过一系列测试确保升级后的系统正常运行。通过这些步骤,可以顺利完成 Struts 2 的版本升级,提升应用的安全性和性能。
178 0
|
3月前
|
SQL 关系型数据库 MySQL
SQL性能调优的神奇之处:如何用优化技巧让你的数据库查询飞起来,实现秒级响应?
【8月更文挑战第31天】在现代软件开发中,数据库性能至关重要。本文通过一个实战案例,展示了从慢查询到秒级响应的全过程。通过对查询的详细分析与优化,包括创建索引、改进查询语句及数据类型选择等措施,最终显著提升了性能。文章还提供了示例代码及最佳实践建议,帮助读者掌握SQL性能调优的核心技巧。
175 0
|
5月前
|
监控 关系型数据库 MySQL
MySQL 查询数据库响应时长详解
- 启用慢查询日志(`slow_query_log`)分析超时查询,调整`long_query_time`阈值。 - 使用`EXPLAIN`检查查询执行计划,优化索引和查询结构。 - `SHOW PROFILE`揭示查询各阶段耗时,辅助性能调优。 - 开启Performance Schema监控服务器,通过`events_statements_summary_by_digest`等表分析性能。 - MySQL Workbench和Percona Toolkit等工具提供额外的性能分析和管理功能。 - 优化技巧:创建合适索引,精简查询,调整数据库配置以提升响应速度。
211 0
|
6月前
|
消息中间件 关系型数据库 Kafka
实时计算 Flink版产品使用合集之使用DTS从RDSMySQL数据库同步数据到云Kafka,增量同步数据延迟时间超过1秒。如何诊断问题并降低延迟
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStreamAPI、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
6月前
|
Cloud Native 关系型数据库 分布式数据库
数据库性能诊断工具DBdoctor通过阿里云PolarDB产品生态集成认证
DBdoctor(V3.1.0)成功通过阿里云PolarDB分布式版(V2.3)集成认证,展现优秀兼容性和稳定性。此工具是聚好看科技的内核级数据库性能诊断产品,运用eBPF技术诊断SQL执行,提供智能巡检、根因分析和优化建议。最新版V3.1.1增加了对PolarDB-X和OceanBase的支持,以及基于cost的索引诊断功能。PolarDB-X是阿里巴巴的高性能云原生分布式数据库,兼容MySQL生态。用户可通过提供的下载地址、在线试用链接和部署指南体验DBdoctor。
347 0
|
SQL 监控 关系型数据库
数据库高效“体检”必备!详解阿里云AnalyticDB MySQL一键诊断功能
AnalyticDB MySQL诊断监控平台则是一套全自研的、从零开始搭建的并紧密贴合分析型系统特征的诊断平台,包含数据的采集(诊断日志和监控数据)、数据缓存(削峰填谷)、清洗转换以及存储等,最终以多种服务形式提供实时的告警、监控、负载洞察、查询分析和诊断等功能。