《Troubleshooting SQL Server》读书笔记-CPU使用率过高（上）

第三章 High CPU Utilization.

CPU使用率过高问题很容易被发现，但是诊断却不是很容易。CPU使用过高很多时候会成为其它问题的替罪羊，所以在确认和故障诊断时要抽丝剥茧。

调查CPU压力

三个主要的工具：性能监视器，SQLTrace,DMV.

     性能监视器：首先用它来确认是SQL Server还是其它进程使用了过多的CPU。主要计数器有：

                     Processor/ %Privileged Time :在特权模式下进程线程执行代码所花时间的百分比。基本可以认为是Windows核心使用的CPU
                     Processor/ %User Time :处理器处于用户模式的时间百分比。应用程序的使用的CPU。
                     Process (sqlservr.exe)/ %Processor Time :SQLServer.exe线程使用处理器执行指令所花的时间百分比。

                     还有一些与SQL Server相关CPU消耗的计数器：

                     SQLServer:SQL Statistics/Auto-Param Attempts/sec
                     SQLServer:SQL Statistics/Failed Auto-params/sec
                     SQLServer:SQL Statistics/Batch Requests/sec
                     SQLServer:SQL Statistics/SQL Compilations/sec
                     SQLServer:SQL Statistics/SQL Re-Compilations/sec
                     SQLServer:Plan Cache/Cache hit Ratio

       SQLTrace: 通过Profiler生成SQLTrace脚本，进行服务器端跟踪，来获得高CPU使用时详细信息。

              DMV：a. 使用sys.dm_os_wait_stats来得到signal wait,确认CPU压力的程度.

                       b. 使用sys.dm_os_wait_stats和sys.dm_os_schedulers观察等待类型

                       c. 使用sys.dm_exec_query_stats和sys.dm_exec_sql_text找出高CPU使用的执行计划和对应的查询

                       d. 使用sys.dm_os_waiting_tasks观察当前与CPU使用相关等待类型

                       e. 使用sys.dm_exec_requests正在执行的查询的资源使用状况

 

调查CPU相关的等待统计：请求执行前，包含请求的会话必需等待，SQL Server会记录等待原因和时间。通过sys.dm_os_wait_stats查询这些信息。

     信号等待时间(Signal wait time)：sys.dm_os_wait_stats的wait_time_ms表示等待类型的总共等待时间，signal_wait_time_ms表示线程收到段义和到重新执行间的等待时间，

                                               这些时间主要花在runnable队列里，是纯CPU等待。

     通过以下查询得到信号等待的时间比率：

   (signal_wait_time_ms)  TotalSignalWaitTime , 
         (  ((signal_wait_time_ms   (20, 2)))  
           /  ((wait_time_ms  (20, 2)))  * 100  ) 
                          PercentageSignalWaitsOfTotalTime 
    sys .dm_os_wait_stats

     也可以查询各类资源等待的比率，下面是等待top 10:

  ( 10 ) 
        wait_type , 
        waiting_tasks_count , 
         ( wait_time_ms - signal_wait_time_ms )  resource_wait_time  , 
        max_wait_time_ms , 
          waiting_tasks_count  
            0   0 
            wait_time_ms / waiting_tasks_count  
            avg_wait_time 
    sys .dm_os_wait_stats 
    wait_type        
                                        
           wait_type      
           wait_type    
( , ,  , 
  , , , 
  ,  , , 
  , , , 
  ,  , , 
   , , 
  ,   ) 
   wait_time_ms

与CPU相关的等待类型主要有SOS_SCHEDULER_YIELD,CXPACKET和CMEMTHREAD

    SOS_SCHEDULER_YIELD: SQL Server计划程序是协同的多任务计划程序。查询占用一小段时间的CPU后自发地让出CPU给后面的查询，

                                      并且回到可运行队列等待重新被运行，这种等待就是SOS_SCHEDULER_YIELD。

                                      如果此等待时间在sys.dm_exec_requests或者sys.dm_os_waiting_tasks过多，则表示有高CPU使用的查询需要优化或者需要增加CPU。

    CXPACKET：多处理器运行并行查询时，当同步多个线程间的查询处理器交换迭代器时出现。

    CMEMTHREAD：等待同步内存对象。有些内存对象是不请允许并发访问的，当多个线程试图访问此内存对象时，就会等待。

   调查计划程序队列(scheduler queues)：scheduler_id<255的是隐藏的系统计划程序，如DAC，备份等。

  scheduler_id  , 
        current_tasks_count, 
        runnable_tasks_count
    sys.dm_os_schedulers
    scheduler_id < 255

      current_task_count表示每个计划程序上的任务数，runnable_task_count表示runnable队列中等待CPU的任务。

 

找出高CPU消耗的查询

      主要使用sys.dm_exec_query_stats和sys.dm_exec_sql_text。下面是占用CPU时间的TOP 10查询：

  ( 10 ) 
         (ST.text, ( QS .statement_start_offset / 2  ) + 1, 
                  ( (  statement_end_offset 
                          -1  DATALENGTH (st.text) 
                          QS .statement_end_offset  
                         - QS .statement_start_offset ) / 2  ) + 1) 
                   statement_text , 
        execution_count  , 
        total_worker_time / 1000  total_worker_time_ms  , 
         ( total_worker_time / 1000 ) / execution_count 
                   avg_worker_time_ms  , 
        total_logical_reads , 
        total_logical_reads / execution_count   avg_logical_reads , 
        total_elapsed_time  / 1000  total_elapsed_time_ms , 
         ( total_elapsed_time  / 1000 ) / execution_count 
                   avg_elapsed_time_ms , 
        qp .query_plan  
    sys .dm_exec_query_stats qs  
           APPLY  sys .dm_exec_sql_text(qs.sql_handle ) st  
           APPLY  sys .dm_exec_query_plan(qs.plan_handle) qp  
   total_worker_time DESC

值得注意的是有些情况下缓存计划是会被清除的，如内存压力，数据库状态改变等。使用了with recompile的SP和option (recompile)提示的语句不会缓存执行计划。

当查询因为某些原因被重编译(统计信息改变，架构改变等)，如果经常发生，则会让执行时间统计变得不准确。所以最好是每隔一段时间抓取缓存计划信息，然后汇总对比。

-------------------------------------

作者：Joe.TJ