CPU性能分析

SQL SERVER性能调优之五(CPU性能分析)

(一)概述

(1)CPU对一台数据库服务器来说,是非常重要的资源。废话少说大家都懂的。

(2)如何监控CPU性能。

2.1 可以使用system perfmon收集Processor:% Processor Time性能计数器,可以参见另一篇文章

SQL SERVER性能调优之二(分析服务器的整体性能)

2.2使用SQL Server Performance Dashboard。

(二)什么原因会导致CPU性能问题?

(1)大量消耗CPU的运算,如哈希运算,排序运算。

(2)执行计划的编译和重编译。

(3)缺乏索引的大量IO操作也会引起额外的CPU消耗。

(4)并行操作。

等等。。。。

(三)具体手段

 (1)几个重要的等待,先确定服务器级别的等待。

SELECT wait_type,
       Sum(signal_wait_time_ms) AS TotalSignalWaitTime
FROM   sys.dm_os_wait_stats
GROUP  BY wait_type
ORDER  BY 2 DESC

CXPACKET等待:等待多个线程同步,会出现此等待。

SOS_SCHEDULER_YIELD:放弃CPU,并等待继续执行。

如果发现大量CXPACKET等待,可能由于并行造成,在OLTP系统,可以考虑降低并行度。

如果发现大量SOS_SCHEDULER_YIELD等待,可能说明你的CPU存在瓶颈。

(2)几个重要的计数器

sql statistics: sql compilations/sec     每秒的查询编译次数

sql statistics: sql recompilations/sec  每秒的查询重编译次数

如果发现以上两个性能计数器的值非常高,可以CPU性能问题有编译造成。可以采用存储过程封装T-SQL语句,参数化查询,紧急时可以开启数据强制参数化。

(3)语句级别处理

SELECT TOP 10 total_worker_time / execution_count       AS [Avg CPU Time],
              (SELECT Substring(text, statement_start_offset / 2, (
                              CASE
                              WHEN statement_end_offset = -1 THEN Len(
                              CONVERT(NVARCHAR(max), text)) *
                                                                  2
                              ELSE statement_end_offset
                                                                    END
                              - statement_start_offset ) / 2
                      )
               FROM   sys.Dm_exec_sql_text(sql_handle)) AS query_text,
              *
FROM   sys.dm_exec_query_stats
ORDER  BY [Avg CPU Time] DESC 
select top 10
    (total_logical_reads/execution_count) as avg_logical_reads,
    (total_logical_writes/execution_count) as avg_logical_writes,
    (total_physical_reads/execution_count) as avg_phys_reads,
     Execution_count,
    statement_start_offset as stmt_start_offset,
    sql_handle,
    plan_handle
from sys.dm_exec_query_stats 
order by  (total_logical_reads + total_logical_writes) Desc

使用该查询可以查询CPU和IO消耗最高的10个语句,可以逐一分析,是否可以更改写法或者适当添加索引,降低CPU使用率(一般高CPU和高IO关联,所以可以想办法先降低IO,直观的处理,就是减少语句的逻辑读)。

(四)总结

CPU优化是一个长期的过程,需要定义将当前的性能计数器和基线对比,尽早的发现问题,CPU出现性能问题,有时候也不一定代表就是CPU出现瓶颈了,可能预示其他硬件出现故障了,或者索引被意外删除了,网站受到攻击等等,所以CPU监控至关重要。

T-SQL之哈希索引

(一)问题提出

1,当表中一个字段过长时,建立索引就不适合的了,建立索引的一个原则就是索引不能太宽。

2,对于varchar(max)、nvarchar(max) 和 varbinary(max) 大值数据类型根本就不能建立索引。

3,对于这个情况怎么办呢?

4,哈希索引就派上了用场。

(二)示例代码

-建立测试表
CREATE TABLE hash_index
  (
     id   INT IDENTITY(1, 1) PRIMARY KEY,
     name VARCHAR(max)
  )
  
go
--插入10000测试数据
WITH cte
     AS (SELECT NUMBER + 1 AS NUMBER
         FROM   master..spt_values a
         WHERE  a.TYPE = 'P'
                AND NUMBER < 100)
INSERT INTO hash_index
            (name)
SELECT Cast(Newid() AS VARCHAR(50)) + Cast(Newid() AS VARCHAR(50)) + Cast(
              Newid() AS VARCHAR(50)) + Cast(Newid() AS VARCHAR(50)) + Cast(
              Newid() AS VARCHAR(50)) + Cast(Newid() AS VARCHAR(50)) + Cast(
              Newid() AS VARCHAR(50))
FROM   cte a
       CROSS JOIN cte b
  
go
--增加计算列
ALTER TABLE hash_index
  ADD cs_name AS Checksum(name);
  
go
--增加索引
CREATE INDEX idx_name
  ON hash_index(cs_name)

 

(三)查询示例

--查询一表扫描
SELECT *
FROM   hash_index
WHERE  name =
'C3AA9897-9303-48C9-B2C2-758C0FFE0BB1ABB3F6FB-BC2C-45DF-B40A-E3DA413AD91E1A598E90-31FE-4F54-B468-0D085A191DA37A35782D-B048-4A6B-89CA-00A15FC1467E0235D0F1-A9EA-4908-9531-3D787C7E7AAA2E6DB162-1099-4B3B-BF93-261B87660B1359768A42-F9F7-4107-9D57-BCB91EEF3CD5'
--查询二哈希索引
SELECT *
FROM   hash_index
WHERE  name =
'C3AA9897-9303-48C9-B2C2-758C0FFE0BB1ABB3F6FB-BC2C-45DF-B40A-E3DA413AD91E1A598E90-31FE-4F54-B468-0D085A191DA37A35782D-B048-4A6B-89CA-00A15FC1467E0235D0F1-A9EA-4908-9531-3D787C7E7AAA2E6DB162-1099-4B3B-BF93-261B87660B1359768A42-F9F7-4107-9D57-BCB91EEF3CD5'
AND cs_name = Checksum(
'C3AA9897-9303-48C9-B2C2-758C0FFE0BB1ABB3F6FB-BC2C-45DF-B40A-E3DA413AD91E1A598E90-31FE-4F54-B468-0D085A191DA37A35782D-B048-4A6B-89CA-00A15FC1467E0235D0F1-A9EA-4908-9531-3D787C7E7AAA2E6DB162-1099-4B3B-BF93-261B87660B1359768A42-F9F7-4107-9D57-BCB91EEF3CD5'

 (四)对比性能消耗
表 'hash_index'。扫描计数 1,逻辑读取 340 次,物理读取 4 次,预读 133 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 'hash_index'。扫描计数 1,逻辑读取 5 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

 

原文地址:https://www.cnblogs.com/Leo_wl/p/2477617.html