sqlserver 2012 服务器cpu长期占用百分之80以上？

[mysky0103]

用的是阿里云服务器，索引已经优化，非聚集索引都没有缺失，用sql profiler 监控sql语句 reads 大于20000的语句 复制出来单独 执行 语句执行都狠快啊，但是cpu还是很高
如果能找出sql语句 执行效率慢的，用sql profiler 设置几个参数 出来语句都差不多的？？

[clark_kidd]

reads 高开销的是硬盘资源，你是CPU资源占用高，仔细看看Duration列，看看有没有耗费太多时间的SQL

[吉普赛的歌]

SELECT OBJECT_NAME(qt.objectid, qt.dbId)  AS procName,
       DB_NAME(qt.dbId)                   AS [db_name],
       qt.text                            AS SQL_Full,
       SUBSTRING(
           qt.text,
           (qs.statement_start_offset / 2) + 1,
           (
               (
                   CASE statement_end_offset
                        WHEN -1 THEN DATALENGTH(qt.text)
                        ELSE qs.statement_end_offset
                   END 
                   - qs.statement_start_offset
               ) / 2
           ) + 1
       )                                  AS SQL_Part --统计对应的部分语句
       ,
       qs.creation_time,
       qs.last_execution_time,
       qs.execution_count,
       qs.last_elapsed_time / 1000000     AS lastElapsedSeconds,
       qs.last_worker_time / 1000000      AS lastCpuSeconds,
       CAST(
           qs.total_elapsed_time / 1000000.0 / (
               CASE 
                    WHEN qs.execution_count = 0 THEN -1
                    ELSE qs.execution_count
               END
           ) AS DECIMAL(28, 2)
       )                                  AS avgDurationSeconds,
       CAST(qs.last_logical_reads AS BIGINT) * 1.0 / (1024 * 1024) * 8060 AS 
       lastLogicReadsMB,
       qs.last_logical_reads,
       qs.plan_handle
FROM   sys.dm_exec_query_stats qs
       CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS p
WHERE  qs.last_execution_time >= CONVERT(CHAR(10),GETDATE(),120)+' 08:00'	--今天8点之后的慢SQL
       AND qs.last_elapsed_time >= 3 * 1000 * 1000							--只取执行时间大于 3 秒的记录
       AND qt.[text] NOT LIKE '%Proc_DBA%'
ORDER BY
       qs.last_worker_time DESC

先在服务器上执行， 看下是哪些SQL慢吧

[mysky0103]

引用 2 楼 z10843087 的回复:

[quote=引用 楼主 lizh0103 的回复:] 用的是阿里云服务器，索引已经优化，非聚集索引都没有缺失，用sql profiler 监控sql语句 reads 大于20000的语句 复制出来单独 执行 语句执行都狠快啊，但是cpu还是很高 如果能找出sql语句 执行效率慢的，用sql profiler 设置几个参数 出来语句都差不多的？？

是RDS,还是ecs，服务器什么配置，CPU很高吧最大并行度调整下，试试看，[/quote] 用的是ecs 服务器配置是CPU： 8核 32G

[OwenZeng_DBA]

引用 楼主 lizh0103 的回复:

用的是阿里云服务器，索引已经优化，非聚集索引都没有缺失，用sql profiler 监控sql语句 reads 大于20000的语句 复制出来单独 执行 语句执行都狠快啊，但是cpu还是很高 如果能找出sql语句 执行效率慢的，用sql profiler 设置几个参数 出来语句都差不多的？？

是RDS,还是ecs，服务器什么配置，CPU很高吧最大并行度调整下，试试看，

[mysky0103]

这个语句是干嘛的版主

select * from OpenRowset(TABLE TRCDATA, @traceid, @records)

[OwenZeng_DBA]

@lizh0103 看看你们的BATCH REQUST 是不是你的并发太高了，,还有看看重编译的次数和每秒编译的次数

[听雨停了]

看看是不是有什么别的未知软件占用了大量cpu

[吉普赛的歌]

引用 5 楼 lizh0103 的回复:

这个语句是干嘛的版主 select * from OpenRowset(TABLE TRCDATA, @traceid, @records)

这是你开跟踪导致的， SqlProfiler 的消耗很大的了， 不应该长期开着。先关了吧。 SQL Server2012 可以用更好的方式来捕获慢SQL： http://blog.csdn.net/yenange/article/details/52592814 你先用这种方式搜集几天的数据再说吧。 也可以在CPU非常高的时候， 立即执行一下我前面的那段SQL， 看下到底是什么占用了CPU。 如果关了sqlprofiler, CPU还是很高， 而且我那段 cpu 里找的sql执行却并不慢， 可以用活动和监视器看一下： http://blog.csdn.net/yenange/article/details/78186536 （刚发布的博客， 需要审核，如果看不了可能要再等一段时间）。

[mysky0103]

引用 8 楼 yenange 的回复:

[quote=引用 5 楼 lizh0103 的回复:]

这个语句是干嘛的版主

select * from OpenRowset(TABLE TRCDATA, @traceid, @records)

这是你开跟踪导致的， SqlProfiler 的消耗很大的了， 不应该长期开着。先关了吧。

SQL Server2012 可以用更好的方式来捕获慢SQL： http://blog.csdn.net/yenange/article/details/52592814

你先用这种方式搜集几天的数据再说吧。

也可以在CPU非常高的时候， 立即执行一下我前面的那段SQL， 看下到底是什么占用了CPU。

如果关了sqlprofiler, CPU还是很高， 而且我那段 cpu 里找的sql执行却并不慢， 可以用活动和监视器看一下：
http://blog.csdn.net/yenange/article/details/78186536
（刚发布的博客， 需要审核，如果看不了可能要再等一段时间）。


[/quote]

SqlProfiler 已经 关了 cpu还是在80 % 左右，
服务器配置是

[吉普赛的歌]

你看一下任务管理器（注意要查看所有用户进程）， 哪个进程占的 CPU 最高？

[clark_kidd]

"SqlProfiler 的消耗很大的了"这点我不认同，请说这句话的人自己测试一下 SqlProfiler 能占多少CPU

引用 5 楼 lizh0103 的回复:

这个语句是干嘛的版主 select * from OpenRowset(TABLE TRCDATA, @traceid, @records)

这行语句前面的 ApplicationName 列是什么？

[OwenZeng_DBA]

@lizh0103 Batch request 每秒多少

[薛定谔的DBA]

cpu 高定位思路：
1. 先确认是不是sql server 进程高，还是系统其他进程引起的。性能监视器可以看到。
2. 同时打开性能计数器，跟踪 System 相关的线程数、cpu等待队列，看cpu是否够用。
3. 如果是sql server 引起的，用性能计数器，监控 连接数、批处理、编译数、死锁数、进程堵塞、表扫描数等，估算是不是用户多引起的。当然以前有监控是最好的，方便对比确认是哪里有问题。（看图也不用再收集几天信息了，全天CPU都是高的）
4. 假设实例内引起的，cpu 高一般是循环sql操作、计算量大，从图上看并不持久，指数频繁。奇怪的是cpu没有突破80%到达100%
，不知道有没有限制。应该是sql 的频繁操作，整体上都是高的，那是系统cpu资源不够，cpu 频数不高、计算慢，应该增加cpu。另一种从sql语句优化，用命令查看当前数据库执行了什么语句，少用 profiler。找出哪些是常运行的sql，哪些运行久的sql，进行优化一般。

[开着拖拉机泡妞]

解决思路：
性能计数器跟踪查看CPU相关的计数器：
Processor: % Processor Time
　　这是监控cpu情况的一个指标（类似于disk time）。这个是观察cpu利用率的一个关键参数。如果Processor Time计数器的值持续超过80%，说明cpu存在瓶颈问题。如果只是偶尔出现，那说明可能是这个时间点有个特别消耗cpu的查询，可以在下一次这个时间点来临的时候尝试抓一下sql并且优化它。如果在某一个时间点以后cpu一直飙高，常见的情况就是：1.突然间的高并发2.索引重整3.突然一个经常使用的数据量特别大的索引失效了4.死锁5.其他好多好多。先找到问题所在，在处理掉它。
System: Processor Queue Length
　　这个指标类似于disk queue length，也是算单个cpu的。单个cpu不能超过2，比如你是2u的机器，那这个值不应该超过4，如果在一个监控周期内持续性的超过4，那就可能出现cpu瓶颈了。

[开着拖拉机泡妞]

引用 15 楼 TravyLee 的回复:

解决思路：
性能计数器跟踪查看CPU相关的计数器：
Processor: % Processor Time
　　这是监控cpu情况的一个指标（类似于disk time）。这个是观察cpu利用率的一个关键参数。如果Processor Time计数器的值持续超过80%，说明cpu存在瓶颈问题。如果只是偶尔出现，那说明可能是这个时间点有个特别消耗cpu的查询，可以在下一次这个时间点来临的时候尝试抓一下sql并且优化它。如果在某一个时间点以后cpu一直飙高，常见的情况就是：1.突然间的高并发2.索引重整3.突然一个经常使用的数据量特别大的索引失效了4.死锁5.其他好多好多。先找到问题所在，在处理掉它。
System: Processor Queue Length
　　这个指标类似于disk queue length，也是算单个cpu的。单个cpu不能超过2，比如你是2u的机器，那这个值不应该超过4，如果在一个监控周期内持续性的超过4，那就可能出现cpu瓶颈了。

如果发现CPU使用率并非一直那么高，建议使用SQL SqlProfiler 跟踪解决问题。跟踪模板就不细说，百度一大把。另外下载个存储过程sp_whoisactive 查看对应结果 。如果有异常，从计数大的结果 一个一个的去解决。