SQL Server内存被操作系统进程占用，如何解决此类案例？

本文共计1460个文字，预计阅读时间需要6分钟。

场景：最近一台DB服务器出现CPU报警，我的邮件报警阈值设置为15%，开始时没有及时回应事，因为是有统计类的查询，后来越来越频繁。

探索：我决定查一下，究竟是怎么回事。

场景：

　　最近一台DB服务器偶尔出现CPU报警，我的邮件报警阈（请读yù）值设置的是15%，开始时没当回事，以为是有什么统计类的查询，后来越来越频繁。

探索：

　　我决定来查一下，究竟是什么在作怪，我排查的顺序如下：

　　1、首先打开Cacti监控，发现最近CPU均值在某天之后骤然上升，并且可以看到System\Processor Queue Length和sqlservr\%ProcessorTime 也在显著的变化。

　　

　　2、从最容易入手的低效SQL开始，考虑是不是最近业务做了什么修改？连接到该SQL实例，打开活动监视器，展开“最近耗费大量资源的查询”，并CPU时间倒序，在这里并未发现有即时的耗费资源的查询。据个人经验，这里的值如果是4位数，分钟内执行次数3位数，一般的服务器CPU大概就10%以上，如果cpu时间那里是5位数，且分钟内执行次数也很高，几百次以上，那CPU一般就会不淡定了。图片仅为演示

　　

　　3、没有耗资源的SQL，这是DBA最不愿意看到的结果，因为也许，SQL Server受到了来自内部或者外部的压力，使得自己花费了过多的时间去处理与操作系统的沟通去了。SQL Server常见的非查询低效类的性能问题，绝大多数都来自于内存或者硬盘，而这两者有的时候需要同时研究对比基线，才能确定谁是因，谁是果。