《Troubleshooting SQL Server》读书笔记-CPU使用率过高(上)
2013-07-16 15:32
134 查看
第三章 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等待。
通过以下查询得到信号等待的时间比率:
[/code]
也可以查询各类资源等待的比率,下面是等待top 10:
[/code]
与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,备份等。
current_task_count表示每个计划程序上的任务数,runnable_task_count表示runnable队列中等待CPU的任务。
找出高CPU消耗的查询
主要使用sys.dm_exec_query_stats和sys.dm_exec_sql_text。下面是占用CPU时间的TOP 10查询:
值得注意的是有些情况下缓存计划是会被清除的,如内存压力,数据库状态改变等。使用了with recompile的SP和option (recompile)提示的语句不会缓存执行计划。
当查询因为某些原因被重编译(统计信息改变,架构改变等),如果经常发生,则会让执行时间统计变得不准确。所以最好是每隔一段时间抓取缓存计划信息,然后汇总对比。
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等待。
通过以下查询得到信号等待的时间比率:
[code]SELECT SUM (signal_wait_time_ms) AS TotalSignalWaitTime , ( SUM (CAST(signal_wait_time_ms AS NUMERIC(20, 2))) / SUM (CAST(wait_time_ms AS NUMERIC(20, 2))) * 100 ) AS PercentageSignalWaitsOfTotalTime FROM sys .dm_os_wait_stats
[/code]
也可以查询各类资源等待的比率,下面是等待top 10:
[code]SELECT TOP ( 10 ) wait_type , waiting_tasks_count , ( wait_time_ms - signal_wait_time_ms ) AS resource_wait_time , max_wait_time_ms , CASE waiting_tasks_count WHEN 0 THEN 0 ELSE wait_time_ms / waiting_tasks_count END AS avg_wait_time FROM sys .dm_os_wait_stats WHERE wait_type NOT LIKE '%SLEEP%' -- remove eg. SLEEP_TASK and -- LAZYWRITER_SLEEP waits AND wait_type NOT LIKE 'XE%' AND wait_type NOT IN -- remove system waits ( 'KSOURCE_WAKEUP', 'BROKER_TASK_STOP', 'FT_IFTS_SCHEDULER_IDLE_WAIT' , 'SQLTRACE_BUFFER_FLUSH', 'CLR_AUTO_EVENT', 'BROKER_EVENTHANDLER', 'BAD_PAGE_PROCESS', 'BROKER_TRANSMITTER' , 'CHECKPOINT_QUEUE', 'DBMIRROR_EVENTS_QUEUE', 'SQLTRACE_BUFFER_FLUSH', 'CLR_MANUAL_EVENT', 'ONDEMAND_TASK_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH' , 'LOGMGR_QUEUE', 'BROKER_RECEIVE_WAITFOR' , 'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS', 'BROKER_TO_FLUSH' ) ORDER BY wait_time_ms DESC
[/code]
与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,备份等。
SELECT scheduler_id , current_tasks_count, runnable_tasks_count FROM sys.dm_os_schedulers WHERE 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查询:
SELECT TOP ( 10 ) SUBSTRING(ST.text, ( QS .statement_start_offset / 2 ) + 1, ( ( CASE statement_end_offset WHEN -1 THEN DATALENGTH (st.text) ELSE QS .statement_end_offset END - QS .statement_start_offset ) / 2 ) + 1) AS statement_text , execution_count , total_worker_time / 1000 AS total_worker_time_ms , ( total_worker_time / 1000 ) / execution_count AS avg_worker_time_ms , total_logical_reads , total_logical_reads / execution_count AS avg_logical_reads , total_elapsed_time / 1000 AS total_elapsed_time_ms , ( total_elapsed_time / 1000 ) / execution_count AS avg_elapsed_time_ms , qp .query_plan FROM sys .dm_exec_query_stats qs CROSS APPLY sys .dm_exec_sql_text(qs.sql_handle ) st CROSS APPLY sys .dm_exec_query_plan(qs.plan_handle) qp ORDER BY total_worker_time DESC
值得注意的是有些情况下缓存计划是会被清除的,如内存压力,数据库状态改变等。使用了with recompile的SP和option (recompile)提示的语句不会缓存执行计划。
当查询因为某些原因被重编译(统计信息改变,架构改变等),如果经常发生,则会让执行时间统计变得不准确。所以最好是每隔一段时间抓取缓存计划信息,然后汇总对比。
相关文章推荐
- 《Troubleshooting SQL Server》读书笔记-CPU使用率过高(上)
- 《Troubleshooting SQL Server》读书笔记-CPU使用率过高(下)
- 《Troubleshooting SQL Server》读书笔记-CPU使用率过高(下)
- 《Troubleshooting SQL Server》读书笔记
- Troubleshooting the Performance of a SQL Server Solution(读书笔记,全是copy原文的)
- 《Troubleshooting SQL Server》读书笔记-性能故障诊断方法论
- 《Troubleshooting SQL Server》读书笔记-磁盘I/O配置
- 《Troubleshooting SQL Server》读书笔记-性能故障诊断方法论
- 《Troubleshooting SQL Server》读书笔记-磁盘I/O配置
- 《Troubleshooting SQL Server》读书笔记-内存管理
- 《Troubleshooting SQL Server》读书笔记-内存管理
- Query performance troubleshooting in SQL Server 2008: query_hash and query_plan_hash
- Troubleshooting deadlock in SQL Server
- How To: Troubleshooting SQL Server I/O bottlenecks
- Troubleshooting SQL Server RESOURCE_SEMAPHORE Waittype Memory Issues
- Troubleshooting Performance Problems in SQL Server 2005
- Note on <Professional SQL Server 2012 Internals And Troubleshooting> - 01
- SQL in SQL Server Trouble-shooting
- 《Troubleshooting SQL Server: A Guide for the Accidental DBA》电子书下载
- 《Microsoft Sql server 2008 Internals》读书笔记--第十一章DBCC Internals(1)