性能测试案例:数据库cpu高导致响应时间长

前几天在用jmeter做性能测试的时候,遇到一个响应时间长的性能问题,简单总结一下,分享给大家,希望能给大家在性能测试过程中类似问题提供一个性能问题分析定位的思路。

现象如下图,响应时间很长,达到了18秒左右,tps也只有20

        监控:

根据经验,直奔oracle数据库服务器,top命令一看,负载高,用户cpu将近100%,cpu已经达到性能瓶颈了,shift+p,或者键盘大写状态下按P,将所有进程按cpu使用率从高到低排序,这样,我们关注消耗cpu最多的进程即可

        分析定位:

直接选取上图第一个进程ID27087,通过下面的sql在plsql中查询(注意:连接oracle数据库的用户需要有v$process、v$session、v$sql这3张表的权限,如果没有,向DBA申请即可,下面sql的含义:通过pid,在v$process中找到paddr,通过paddr在v$session中找到sql_id,通过sql_id在v$sql中找到对应的sql)
查出来一条结果

点击下面

可以看到完整的sql语句,是一个多表关联查询语句,它很耗数据库cpu,顺其自然的想到去看下表的索引

查看表,发现where后条件字段不是索引字段

        调优总结:

编辑表,果断把该字段加为索引字段,重新压测,数据库服务器基本上就没啥负载了,且cpu基本都是空闲状态

响应时间也只有几十毫秒了

tps从20左右提升到300多,可以说性能提升是相当的明显

总结:sql一直占用cpu切片时间,其它线程就只能等待,服务器负载高,所以响应时间就长了。

文章转自:https://mp.weixin.qq.com/s?__biz=MzIxMzMxMDcwNA==&mid=2247484089&idx=1&sn=35de1f750c5a8e42f12e48a8535b3963&source=41#wechat_redirect

原文地址:https://www.cnblogs.com/hopeiscoming/p/12609743.html

时间: 2024-10-09 04:25:02

性能测试案例:数据库cpu高导致响应时间长的相关文章

性能测试三十九:Jprofiler分析CPU过高和响应时间长的问题

使用Jprofiler监控分析案例 一.cpu负载过高:http://localhost:8080/PerfTeach/CpuTopServlet?id=1 cpu消耗高的可能原因1.使用了复杂的算法,比如加密.解密2.压缩.解压.序列化等操作3.代码bug,比如死循环 dstat监控起来,先看一下资源是否正常,用5个并发跑60秒 CPU:100% TPS才几百,肯定就有问题 TOP:JAVA占的CPU最多 查看进程,是tomcat 使用jprofiler查看,很明显有个自己写的userToSt

【故障公告】再次出现数据库 CPU 居高不下的问题以及找到了最可能的原因

非常非常抱歉,今天上午的故障又一次给大家带来麻烦了,再次恳请大家的谅解. 在昨天升级阿里云 RDS SQL Server 实例的配置后(详见昨天的博文),万万没有想到,今天上午更高配置的阿里云 RDS 实例依然出现了 CPU 居高不下的问题. 在数据库 CPU 高的情况下,有时对访问速度影响不大,有时巨慢无边,在今天上午的故障期间,我们通过2次主备切换才恢复了正常. 下午,我们我们调整了服务器的部署,用了更多服务器进行混合部署(docker-compose与docker swarm),情况有了明

一个查询交易导致数据库CPU使用率高的问题

这一阵子在做一个查询交易的压力测试,使用的AIX+informix数据库.应用和数据库分别部署在两台机器上.使用loadrunner进行并发测试.相关表的历史数据是20W级别的.使用20个并发进行测试. 测试过程中,应用服务器负载正常,数据库服务器磁盘.网络使用率正常,但是CPU使用率却是98%左右.觉得很奇怪,因为这台机器是测试环境中性能最好的,表现不应该如此.于是先猜测会不会是informix的参数配置不对,于是搜了些informix参数中影响CPU使用率的参数调了一遍,但是现象依旧.对里面

MySQL SYS CPU高的案例分析(一)

原文:MySQL SYS CPU高的案例分析(一) [现象] 最近关注MySQL CPU告警的问题时,发现有一种场景,有一些服务器最近都较频繁的出现CPU告警,其中的现象是 SYS CPU占比较高. 下面的截图来源于“MySQL CPU报警”采集的文件 [问题分析] 可以分析出这服务器CPU升高的原因是由于表的高并发写入引起.优化方案通常是通知开发停止写入或降低写入频率. 究竟是什么原因导致高并发写入时CPU sys的占比这么高. 从采集的[Perf Stat]指标看到CPU有大量消耗是集中ke

阿里云RDS优化MySQL,解决数据库CPU占用高

登录RDS数据库 第一步先看MYSQL的性能状况,分析是设置问题还是SQL效率问题 使用实例信息/实时性能 发现read数据比较高,同时发现数据库CPU占用较高 再通过实时回话观察使用频繁的SQL,并且较慢的SQL 在诊断报告中也可以找出慢SQL,优先解决执行次数多的慢SQL,有些报表只执行了1-2次可以不用关注. 将慢SQL在SQL执行窗口中执行,并查看执行计划 对于这种TYPE=ALL全表扫描的返回rows很多的就需要进行优化 这次优化主要发现两个地方: 1. MySQL中datediff函

中断ORACLE数据库关闭进程导致错误案例

昨晚下班的时候,我准备关闭本机的虚拟机上的ORACLE数据库后准备下班,但是由于我SecureCRT开了多个窗口,结果一不小心,疏忽之下在一个生产服务器上执行了shutdown immediate命令,大概过了6到7秒,发现该命令还没有响应,我才发现我这个命令执行错了服务器.一惊之下,想都没有想直接CTRL+C想中断这个操作. 如下所示: SQL> shutdown immeidate; SP2-0717: illegal SHUTDOWN option SQL> shutdown immed

[转]检测SQLSERVER数据库CPU瓶颈及内存瓶颈

在任务管理器中看到sql server 2000进程的内存占用,而在sql server 2005中,不能在任务管理器中查看sql server 2005进程的内存占用,要用 以下语句查看sql server 的实际内存占用: select * from sysperfinfo where counter_name like '%Memory%' 其中, Total Server Memory 表示内存占用. select locked_page_allocations_kb  from sys

MYSQL数据库服务CPU高问题分析与优化

MySQL服务性能监控分析与优化是永恒的主题,做为性能测试人员有时也要站在DBA角度出发进行适当分析与优化,这也是性能测试人员能长期生存发展之路.而资源的使用监控分析才是性能故障分析的根本首要任务.在数据库服务器内部,如果执行的操作会严重受到内存.CPU或磁盘吞吐量中任何一个的影响,则可以将它视为瓶颈. 因此理解服务器如何运行,资源损耗在哪些方面对问题进行故障诊断是非常有价值有意义的活动,具体案例如下. 这些监控分析优化方法等细节我们在品课学院性能实战课堂中都会以实战方式进行实操性测试监控分析实

入门级----黑盒测试、白盒测试、手工测试、自动化测试、探索性测试、单元测试、性能测试、数据库性能、压力测试、安全性测试、SQL注入、缓冲区溢出、环境测试

黑盒测试 黑盒测试把产品软件当成是一个黑箱子,只有出口和入口,测试过程中只要知道往黑盒中输入什么东西,知道黑盒会出来什么结果就可以了,不需要了解黑箱子里面是如果做的. 即测试人员不用费神去理解软件里面的具体构成和原理,只要像用户一样看待产品就可以了. 例如银行转账功能,不需要知道转账的具体实现代码是怎样工作的,只需要把自己想象成各种类型的用户,模拟多种转账情况看系统是否能正常转账即可. 但是仅仅像用户一样去测试又是不够的.如果只做黑盒测试,必然是存在一定的风险的. 例如某个安全性较高的软件系统,