【IT168 评论】最近一台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常见的非查询低效类的性能问题，绝大多数都来自于内存或者硬盘，而这两者有的时候需要同时研究对比基线，才能确定谁是因，谁是果。在这里，我们首先查看SQL Server内存使用情况，当打开性能计数器时，我和我的小伙伴们都惊呆了……安装了64G内存的数据库，SQL Server的TargetMemory仅有500多兆!这其中StolenPage还占用了200多兆，数据库DataPage仅有200多兆的内存可供使用，Oh，Shit!虽然我很不想用“去哪了”这三个字，但是“我的内存去哪了“?同时我们也注意到PageLifeExpectancy值只有26(一个内存充足的服务器，这个值至少应该是上W的)，而很早之前我们津津乐道的"Cache Hit Ration"却仍然保持一个比较高的水准98! 这个案例告诉我们，缓存命中率这个性能计数器很多时候说明不了什么问题。
