CPU持续100%分析并解决

合集 - SQL Server数据库运维(59)

1.SQL SERVER日常运维巡检系列之-日志2024-12-30 2.关于SQL Server镜像的一个小误区2016-07-02 3.一切从“简”，解放IT运维人员2016-12-16 4.CPU问题定位与解决2017-02-07 5.数据库优化案例——————某市中心医院HIS系统2017-01-18 6.系统隐形杀手——阻塞与等待2017-01-11 7.SQL Server常见问题介绍及快速解决建议2016-12-20 8.tempdb日志文件暴增分析2022-11-09 9.数据库服务器CPU不能全部利用原因分析2022-11-07 10.如何快速定位TempDB产生问题2017-02-28 11.索引的重要性2017-02-16 12.SQL语句的优化建议2017-02-14 13.通过分析等待类型解决系统产生问题2017-02-13 14.磁盘问题定位与解决2017-02-09 15.内存问题定位与解决2017-02-08 16.写给数据库运维的兄弟2023-02-27 17.为什么带NOLOCK的查询语句还会造成阻塞2023-02-23 18.链接服务器查询导致的阻塞2023-02-21 19.CXPACKET等待类型分析2023-02-20 20.为什么sleeping的会话会造成阻塞(2)2023-02-17 21.为什么sleeping的会话会造成阻塞2023-02-14 22.为SQL Server配置连接加密2023-02-14 23.SQL SERVER——高可用技术概述2023-02-04 24.数据库服务器CPU不能全部利用原因分析2023-01-15 25.管理工具造成的阻塞2023-01-09 26.自动增长配置不合理导致的性能抖动2023-01-05 27.Profiler导致的严重性能问题2023-01-02 28.CPU持续100%分析并解决分析2022-12-26 29.tempdb大量闩锁等待问题分析2022-11-29 30.探究SQL SERVER 更改跟踪2022-11-15 31.tempdb数据文件暴增分析2022-11-10 32.SQL SERVER 2016 AlwaysOn 无域集群+负载均衡搭建与简测2024-12-16 33.Moebius兼容AlwaysOn2024-12-16 34.Moebius for SQL Server2024-12-16 35.SQL SERVER日常运维巡检系列——数据库备份2024-12-09 36.SQL SERVER日常运维巡检系列——结构设计2024-11-26 37.Moebius for SQL Server2024-11-20 38.SQL SERVER日常运维巡检系列之-数据库2024-10-09 39.【能力提升】SQL Server常见问题介绍及快速解决建议2024-06-19 40.CDC作业历史记录无法删除问题2024-03-04 41.为Oracle链接服务器使用分布式事务2023-11-21 42.大事务导致数据库恢复时间长2023-10-25 43.SQL Server关于AlwaysOn的理解-读写分离的误区(一)2023-09-14 44.链接服务器导致SQL Server停止响应2023-09-05 45.简单配置Sql专家云2023-07-31 46.SQL专家云回溯某时间段内的阻塞2023-07-04 47.SQL专家云快速解决阻塞2023-06-19 48.SQL专家云汇总低效的SQL语句2023-06-05 49.数据库优化案例—某市中心医院HIS系统2023-05-19 50.细说数据库协作运维2023-05-08 51.医院核心数据库一体化建设实践2023-04-24 52.【能力提升】SQL Server常见问题介绍及快速解决建议2023-04-17 53.Moebius数据库多活集群2023-04-10 54.30分钟带你熟练性能优化的那点儿事儿（案例说明）2023-04-03 55.SQL Server底层架构技术对比2023-03-28 56.Moebius兼容AlwaysOn2023-03-23 57.透过等待看数据库2023-03-21 58.数据库自动收缩造成的阻塞2023-03-09

59.CPU持续100%分析并解决2023-03-02

背景

接到客户电话，说某系统数据库服务器CPU利用率从上午8点开始到现在基本上都是100%的情况，影响到了业务。让给看看是什么原因导致的，怎么紧急处理一下。

现象

查看CPU利用率，确实一直是90%以上的情况。

在CPU高的地方查看当时运行的语句，发现有一类语句并发量非常大，且大多数的运行状态为runnable（等待执行）。runnable代表这个会话没有资源等待，可以执行，但没有 CPU 可用，可以理解为正在等待 CPU 这项系统资源。出现这种等待，往往是系统没有足够的CPU来处理并发任务。

基本上可以确定导致CPU高的原因就是这条语句了。

语句内容：

 1 SELECT
 2         sendtaskvi0_.idAS id1_0_,
 3         sendtaskvi0_.click_urlAS click_ur2_0_,
 4         sendtaskvi0_.create_timeAS create_t3_0_,
 5         sendtaskvi0_.crf_nameAS crf_name4_0_,
 6         sendtaskvi0_.ysmcAS ysmc37_0_
 7 FROM
 8         dcrf_all_**** sendtaskvi0_
 9 WHERE
10         sendtaskvi0_.stage_id= @P0
11         AND sendtaskvi0_.person_id = @P1
12         AND sendtaskvi0_.plan_module_num = @P2
13         AND sendtaskvi0_.task_type = @P3
14         AND sendtaskvi0_.xh = @P4
15         AND sendtaskvi0_.table_name = @P5
16         AND sendtaskvi0_.sf_status <> @P6

dcrf_all_**** sendtaskvi0_ 为视图，定义如下图：

分析

通过SQL专家云智能分析，提示视图里相关的两个表并没有相应的索引，通过专家云生成的两个创建索引的脚本执行创建。

解决

创建索引后CPU得到明显下降：

活动会话数量明显下降：

索引的重要性

一个系统的整体缓慢往往都是因为索引问题导致的，优化索引是对系统最简单的保养。不要小看一条语句的威力，一条语句足可以让你的系统彻底无法工作，相反优化一条重要的高频语句就可以让你的系统变的流畅。

北京格瑞趋势科技有限公司是聚焦于数据服务的高新技术企业，成立于2008年，创始团队及核心技术人员来自微软和雅虎。微软数据平台金牌合作伙伴，卫宁健康数据平台战略合作伙伴。通过产品+服务双轮驱动的业务模式，14年间累计服务4000+客户，覆盖互联网、市政、交通、电信、医疗、教育、电力、制造业等各个领域。