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

非常非常抱歉,今天上午的故障又一次给大家带来麻烦了,再次恳请大家的谅解。

在昨天升级阿里云 RDS SQL Server 实例的配置后(详见昨天的博文),万万没有想到,今天上午更高配置的阿里云 RDS 实例依然出现了 CPU 居高不下的问题。

在数据库 CPU 高的情况下,有时对访问速度影响不大,有时巨慢无边,在今天上午的故障期间,我们通过2次主备切换才恢复了正常。

下午,我们我们调整了服务器的部署,用了更多服务器进行混合部署(docker-compose与docker swarm),情况有了明显改善。

但是,15:15 开始数据库 CPU 又飚了上去,但访问速度没有受到明显影响,一致坚持到 16:50 左右,在扛不住的时候,我们再次通过主备切换恢复了正常。

这次恢复正常后,我们才突然想到,数据库每天一大早会跑一个整理索引碎片的任务,是不是升级后这个任务不能正常执行了?打开 SSMS 一看,果然是。

昨天因为升级 SQL Server 后重建备库,整理索引碎片任务失败了。

Date		9/5/2019 06:30:00
Log		Job History (Reorganize Index)

Step ID		1
Server		SD39184A
Job Name	Reorganize Index
Step Name	Reorganize Index
Duration	00:00:00
Sql Severity	14
Sql Message ID	927

Message
Executed as user: xxx. Database ‘xxx‘ cannot be opened. It is in the middle of a restore. [SQLSTATE 42000] (Error 927).  The step failed.

今天不知什么原因整理索引碎片的任务也失败了。

Date		9/6/2019 06:30:00
Log		Job History (Reorganize Index)

Step ID		1
Server		SD39184A
Job Name	Reorganize Index
Step Name	Reorganize Index
Duration	00:00:00
Sql Severity	14
Sql Message ID	954

Message
Executed as user: xxx. The database "xxx" cannot be opened. It is acting as a mirror database. [SQLSTATE 42000] (Error 954).  The step failed.

CPU 高的问题很可能就是索引碎片没有被及时整理引起的,是否真的是这个原因,要等下周的访问高峰才能得到验证。

对于升级后整理索引碎片任务失败的问题,我们向阿里云提交工单后,阿里云建议我们先关闭 mirror database 。

alter database 库名 set partner off

目前我们没有采用这个建议,还在考虑更好的解决方法。

原文地址:https://www.cnblogs.com/cmt/p/11475531.html

时间: 2024-10-09 04:24:53

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

[转]检测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

SQL Server 2008性能故障排查(二)——CPU

原文:SQL Server 2008性能故障排查(二)--CPU 承接上一篇:SQL Server 2008性能故障排查(一)--概论 说明一下,CSDN的博客编辑非常不人性化,我在word里面都排好了版,贴上来就乱得不成样了.建议CSDN改进这部分.也请大家关注内容不要关注排版.同时在翻译的过程中本人也整理了一次思路,所以还似乎非常愿意翻译,虽然有点自娱自乐,但是分享给大家也是件好事 CPU 瓶颈: CPU瓶颈可能因为某个负载所需的硬件资源不足而引起.但是过多的CPU使用通常可以通过查询优化(

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

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

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

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

sql数据库cpu占用100问题查询

转载    原作者  xunziji SQL Server Cpu 100% 的情况并不太常见,一般引起 SQL Server 产生性能问题的,都是 阻塞.连接数.IO 磁盘等.所以,一般SQL Server 的使用率都是比较低的.但是,在有些情况下,还是会出现Cpu 100%的情况的. SQL Server 在做哪些操作的时候,会比较集中使用 CPU 资源呢?常见的主要如下: 常见的原因: 1. 编译和重编译 编译是 SQL Server 为指令生成执行计划的过程.SQL Server 要分析

新装建exchange Database后,增加副本时,出现如下故障,重新载数据库后,仍提示复

新装建exchange Database后,增加副本时,出现如下故障,重新载数据库后,仍提示复制状态失败. [原因分析] 在之前为database03创建副本时,出现个邮箱服务器数据库不能超过5个,超过后需要激活,而我做了对exchange服务器激活操作后,提示过需要在重启后方可正常生效,重启存储该副本的服务器后,该数据库显示被正常加载.

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

前几天在用jmeter做性能测试的时候,遇到一个响应时间长的性能问题,简单总结一下,分享给大家,希望能给大家在性能测试过程中类似问题提供一个性能问题分析定位的思路. 现象如下图,响应时间很长,达到了18秒左右,tps也只有20         监控: 根据经验,直奔oracle数据库服务器,top命令一看,负载高,用户cpu将近100%,cpu已经达到性能瓶颈了,shift+p,或者键盘大写状态下按P,将所有进程按cpu使用率从高到低排序,这样,我们关注消耗cpu最多的进程即可         

[转]定位占用oracle数据库cpu过高的sql

今天在吃饭的时候我的朋友的数据库出现了问题,cpu占用率为97%,当我看到这个问题的时候我就想到了或许是sql导致的此问题,由于忍不住吃饭,暂时没有帮他看这个问题,这是我饭后自己模拟的故障,进行的分析: 1)查看一下cpu进程占用情况: 看到oracle进程为6331,6517等这几个进程占用cpu过高. 2)查看相关进程信息: [[email protected] ~]$ ps -ef | grep 6331 oracle 6331 1 23 20:24 ? 00:02:05 ora_vktm

mysql数据库cpu、mem使用率高的解决案例

故障: 晚上大概7点钟左右,收到播放中心投诉,说视频播放很慢,加载很久不出来.一开始,哥以为是tomcat服务又挂了.所以到tomcat服务器上查看下catalina.out输出日志.却没发现任务错误信息. 分析: 想了想,视频加载慢,会不会是数据库问题呢?果断上mysql数据库(从库)看下top如下: PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND    37258 mysql    20   0 17.2g