ベンダーSQL Server DBで過剰なCPU使用

dba.stackexchange https://dba.stackexchange.com/questions/106246

質問

背景：ベンダーによって提供されたSQL Server 2012 dbを持っているので、クエリとテーブルの変更は限られています。 DBを所有しているので、インデックスを追加して管理できます。

インデックスは維持されていないか再構築されていません。

私は重要なメモリまたはディスクIOの圧力を見ていません。これは比較的軽く使われるOLTPシステムです。

2つの質問：

  1. DB全体の日付の統計と高度に断片化されたインデックスは、過度のCPUを使用しますか？

  2. 以下にリストされているウェイト統計の組み合わせは、索引の断片化の説明を信用しませんか？

    3. 情報：

    WaitType                                    Wait_S
---------------------------------           -----------    
CXPACKET                                    773345.21
PAGELATCH_UP                                737295.83
SOS_SCHEDULER_YIELD                         140425.24
LATCH_EX                                    69877.95
RESOURCE_SEMAPHORE_QUERY_COMPILE            60985.48
LCK_M_SCH_S                                 39488.17
    . 待機結果に対する

    ソースクエリ：

    WITH [Waits] AS
(
 SELECT
     [wait_type],
     [wait_time_ms] / 1000.0 AS [WaitS],
     ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
     [signal_wait_time_ms] / 1000.0 AS [SignalS],
     [waiting_tasks_count] AS [WaitCount],
     100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
     ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
 FROM 
     sys.dm_os_wait_stats
 WHERE 
     [wait_type] NOT IN (... common waits )
     AND [waiting_tasks_count] > 0)
SELECT
    MAX ([W1].[wait_type]) AS [WaitType],
    CAST (MAX ([W1].[WaitS]) AS DECIMAL (16,2)) AS [Wait_S],
    CAST (MAX ([W1].[ResourceS]) AS DECIMAL (16,2)) AS [Resource_S],
    CAST (MAX ([W1].[SignalS]) AS DECIMAL (16,2)) AS [Signal_S],
    MAX ([W1].[WaitCount]) AS [WaitCount],
    CAST (MAX ([W1].[Percentage]) AS DECIMAL (5,2)) AS [Percentage],
    CAST ((MAX ([W1].[WaitS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgWait_S],
    CAST ((MAX ([W1].[ResourceS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgRes_S],
    CAST ((MAX ([W1].[SignalS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgSig_S]
FROM [Waits] AS [W1]
INNER JOIN [Waits] AS [W2] ON [W2].[RowNum] <= [W1].[RowNum]
GROUP BY [W1].[RowNum]
HAVING SUM ([W2].[Percentage]) - MAX ([W1].[Percentage]) < 95;
    .

役に立ちましたか？

解決

インデックスは維持されていないか再構築されていないので、30％+断片化に座っています...これは私の最初の疑いのある疑いの容疑者であり...

と

DB全体の日付の統計と高度に断片化されたインデックスは、過剰なCPUが使用されますか？

これは部分的に当てはまります。インデックスフラグメンテーションは、高いCPUを引き起こします。内部の断片化は、ページ上にたくさんの空き容量があることを意味し、インデックスをスキャンするのに時間がかかります。これはより多くのディスクIOが発生し、（インデックスページ内の空きスペースのために）インデックスを保存するためのより多くのメモリが必要になります。これは、バッファプール内のより無駄なスペースを意味します。

悪い統計情報により、クエリオプティマイザが非効率的な（不良）プランを生成させると、SQL Serverが作るので、2秒2秒かかるクエリに劣化したパフォーマンスが低下します。悪い推測（例えば、実際の2m行とは対照的に1列）を選択し、読み取り数が多いか、不良結合を選択できるInapapePrate結合を選択することができます。ハッシュまたはマージの参加がより良い選択されたところであるとネストしたループ。悪い（時代遅れまたは古い）統計はあなたのCPUをはるかに高いレベルでPEGにします。

だからあなたの統計と索引を最適化し続けることは間違いなく役立ちます。あなた自身の解決策を作成する代わりに、 Olaのインデックスを使用することをお勧めします。メンテナンスソリューション

Kendra's Excellent Post：//www.breftozar.com/archive/2014/04/index-fragmentation-bad-statistics-arent-always-problem-video/ "rel=" NOFOLLOW NOREFERRER ">インデックスの断片化と悪い統計が必ずしも問題（ビデオ）ではありませんか？

Remus Rusanuには、本当に良いブログ投稿があります。 SQL Serverのパフォーマンス （注意：フォローしない）

このシステムから下記の待機統計の組み合わせは、索引の断片化の説明を信用しませんか？

インデックスの断片化について心配するためだけに、SQL Server構成レベルでもより多くのものがあるかもしれないと思います。また、CXPacketはそれ自体が問題ではありません。

チェックするもの：

Glenn Berryの診断クエリ - 2012バージョン 

-- Signal Waits for instance  (Query 27) (Signal Waits)
SELECT CAST(100.0 * SUM(signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2)) 
AS [% Signal (CPU) Waits],
CAST(100.0 * SUM(wait_time_ms - signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2)) 
AS [% Resource Waits]
FROM sys.dm_os_wait_stats WITH (NOLOCK) OPTION (RECOMPILE);

-- Signal Waits above 15-20% is usually a sign of CPU pressure
.

と

-- Top Cached SPs By Total Worker time (SQL Server 2012). Worker time relates to CPU cost  (Query 44) (SP Worker Time)
SELECT TOP(25) p.name AS [SP Name], qs.total_worker_time AS [TotalWorkerTime], 
qs.total_worker_time/qs.execution_count AS [AvgWorkerTime], qs.execution_count, 
ISNULL(qs.execution_count/DATEDIFF(Second, qs.cached_time, GETDATE()), 0) AS [Calls/Second],
qs.total_elapsed_time, qs.total_elapsed_time/qs.execution_count 
AS [avg_elapsed_time], qs.cached_time
FROM sys.procedures AS p WITH (NOLOCK)
INNER JOIN sys.dm_exec_procedure_stats AS qs WITH (NOLOCK)
ON p.[object_id] = qs.[object_id]
WHERE qs.database_id = DB_ID()
ORDER BY qs.total_worker_time DESC OPTION (RECOMPILE);

-- This helps you find the most expensive cached stored procedures from a CPU perspective
-- You should look at this if you see signs of CPU pressure
.

追加的なJoe Sackは SQL Server CPUのパフォーマンスの問題のトラブルシューティング方法論

ライセンス： CC-BY-SA と 帰属
所属していません dba.stackexchange
scroll top