web-dev-qa-db-ja.com

SQL Server 2012は2008より遅い

大規模なWebサイトとデータベースを古いサーバーから移行しました（Windows 2008/SQL Server 2008/16 GB RAM/2 x 2.5 GHz Quad Core/SASディスク）新しい、より優れたサーバー（Windows 2008 R2/SQL Server 2012 SP1/64 GB RAM/2 x 2.1 GHz 16コアプロセッサー/ SSDディスク）に）。

古いサーバーのデータベースファイルをデタッチし、コピーして新しいサーバーにアタッチしました。すべてがうまくいきました。

その後、互換性レベルを110に変更し、統計を更新し、インデックスを再構築しました。

私の大きな失望に、新しいSQL 2012サーバーでは、ほとんどのSQLクエリが古いSQL 2008サーバーよりもはるかに遅い（2-3-4倍遅い）ことに気づきました。

たとえば、約70万レコードのテーブルでは、古いサーバーではインデックスのクエリに約100ミリ秒かかりました。新しいサーバーでは、同じクエリに約350ミリ秒かかります。

すべてのクエリで同じことが起こります。

ここでいくつかの助けをいただければ幸いです。確認/確認する内容を教えてください。新しいSQL Serverを備えたより良いサーバーでは、パフォーマンスが悪いと信じるのが非常に難しいので。

詳細：

メモリは最大に設定されています。

私はこのテーブルとインデックスを持っています：

CREATE TABLE [dbo].[Answer_Details_23](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [UserID] [int] NOT NULL,
    [SurveyID] [int] NOT NULL,
    [CustomerID] [int] NOT NULL default 0,
    [SummaryID] [int] NOT NULL,
    [QuestionID] [int] NOT NULL,
    [RowID] [int] NOT NULL default 0,
    [OptionID] [int] NOT NULL default 0,
    [EnteredText] [ntext] NULL,
 CONSTRAINT [Answer_Details_23_PK] PRIMARY KEY NONCLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

CREATE NONCLUSTERED INDEX [IDX_Answer_Details_23_SummaryID_QuestionID] ON [dbo].[Answer_Details_23]
(
    [SummaryID] ASC,
    [QuestionID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

私はこのクエリを実行しました：

set statistics time on;
select summaryid, count(summaryid) from Answer_Details_23 group by summaryid order by count(summaryid) desc;
set statistics time off;

古いサーバー-SQLサーバーの実行時間：CPU時間= 419ミリ秒、経過時間= 695ミリ秒。

新しいサーバー-SQL Server実行時間：CPU時間= 1340ミリ秒、経過時間= 1636ミリ秒。

ここにアップロードされた実行計画： http://we.tl/ARbPuvf9t8

その後の更新：

  • AMD 2.1GHz Opteron 16コアプロセッサはIntel 2.5GHzクアッドコアプロセッサよりもはるかに悪い
  • ウィンドウの電源オプションをバランシングからハイパワーに変更する大きな改善
  • 最大並列度を8に、コストしきい値を4に変更してさらに改善

SQL Serverの実行時間：CPU時間= 550ミリ秒、経過時間= 828ミリ秒。

それは古いサーバーよりもさらに悪いですが、それほど悪くはありません。 （ローカルクエリの最適化以外の）他の提案がある場合は、コメントしてください。

sql-serverperformancesql-server-2012
16
prog_sr08

SQL Serverでも同様の問題が発生しました。サーバーが最適に構成されていない可能性があります。新しいXeonには、サーバーのパフォーマンスに大きな影響を与える可能性があるTurboBoost、HTなどが付属しています。

たとえば、私たちは成功しました。 Dellサーバーの低遅延構成

設定はDell以外のサーバーに適用されますが、名前が異なる場合があります。

また、Windowsの電源管理プロファイルを[バランス]から[高パフォーマンス]に設定することにより、パフォーマンスを向上させました。最後の部分は、x64サーバーのOSに最大8 GBのメモリを予約することをお勧めします。デフォルトのSQLインストールではすべてのメモリが使用されます。 SQL Serverの最大メモリ構成を合計メモリよりも4/8GB少ない値に設定して、4/8GBの予約を試すことをお勧めします。

可能であれば、古いサーバーに戻すことをお勧めします。使用可能な回帰/自動化/ロードスクリプトがない場合は、システムアクティビティを1〜4時間記録し、アクティビティが多い期間に記録することをお勧めします。次に、本番環境と同じWebサーバーと、スクリプトを実行するクライアントマシンをセットアップします。新しいサーバーに対して同じアクティビティを実行し、構成を変更して、同じアクティビティを再度実行します。本当にもっと多くのことをしたいと思うでしょうが、それが実行可能であり、この質問の範囲外であるとは思われません。

8
AceCTO

確認/確認する内容を教えてください

パフォーマンスに問題があります。 Waits and Queues のようなパフォーマンスのトラブルシューティング方法論に従って、ボトルネックを特定します。リンクされた方法論は、何をどのように測定するかを示します。調査結果をここに投稿してください。実際の測定に基づいて特定のアドバイスを提供できます。それはあまりにも開放的で誰の推測でもあります。それを特定の問題に絞り込むと、推測作業がなくなります。

更新後

計画はかなり異なります。古い計画では、スタックのストリームの総計が低く、実際にはカーディナリティの推定値が低い（141k対108k）と、ハッシュの計算がさらに誤った予測をしている（35k対108k）。新しい計画では、ストリームの集計がなく、正確な見積もりがトップまであります。もちろん、これは古い計画が（​​== --- ==）より速く実行された理由を説明していません。

下のスキャンの行番号はわずかに異なりますが（重要ではありません）、コストはまったく異なります。古いものは2.49884（IO 2.28979 CPU 0.20905）と新しい1.59109（IO 1.53868 CPU 0.0524084）です。ここでも、2012年の実行が改善されることを示します（インデックスの再構築により、断片化が軽減されたのでしょうか？）.

非常に異なるのは、スレッドの数です。32が新しい（それぞれが23,000行を取得）と8が古い（それぞれが95,000行を取得）です。テーブルはかなり狭いです。 キャッシュの無効化 の方がはるかに頻繁であるため、多数のスレッドが実際にパフォーマンスを低下させている可能性があります。私はしようとします：

  1. 新しいサーバー構成（存在する場合）でハイパースレッディングを排除する、および/または
  2. dOP 8でクエリを試してください。

あなたのコメントに気づきました：

Maxdop 8を使用した実行プランを追加しましたクエリは実際にはこの方法で高速です

おそらく、CPUが互いにつま先を踏んでいるだけです。 SSDが配置されている場合、IOはおそらくほとんど何もないので、テーブルが小さすぎて32台のスキャナーを保証できません。その交換スワップにより、L1/L2が絶えず無効になっている可能性があります。

8
Remus Rusanu

最新のマルチコアシステム、特にマルチCPUシステムのハードウェアアーキテクチャでは、メモリの特定の部分が特定のコア/プロセッサから遠く離れ、メモリの特定の部分が特定のコア/プロセッサに近くなっています。これは、Non-Uniform Memory Architecture、略してNUMAと呼ばれます。 MAXDOP設定をNUMAノードあたりのコア数と一致させて、特定のNumaノードがデータ用に独自のメモリの外に出る必要がある回数を最小限に抑える必要があります。

以下を使用して新しいマシンの構成を確認し、MAXDOPが最適な設定hardware-wiseに設定されていることを確認できます。

DECLARE @CPUs int;
DECLARE @NumaNodes int;
DECLARE @ServerRAMInMB int;

SET @ServerRAMinMB = (SELECT (i.physical_memory_kb / 1024) AS ServerMemory 
    FROM sys.dm_os_sys_info i);
SET @CPUs = (SELECT i.cpu_count from sys.dm_os_sys_info i);
SET @NumaNodes = (SELECT MAX(c.memory_node_id) + 1 FROM sys.dm_os_memory_clerks c 
    WHERE memory_node_id < 64);

SELECT @ServerRamInMB, @CPUs, @NumaNodes;

IF @CPUs > 4 /* this would be 4 cores, not 4 CPUs */
BEGIN
    DECLARE @MaxDOP int;
    SET @MaxDOP = @CPUs * 0.75;
    IF @MaxDOP > (@CPUs / @NumaNodes) SET @MaxDOP = (@CPUs / @NumaNodes);
    EXEC sp_configure 'max degree of parallelism', @MaxDOP;
    EXEC sp_configure 'cost threshold for parallelism', 4; 
END

@ServerRamInMBパラメータを使用して、Max Server MemoryおよびMin Server Memory構成オプションを特定のサーバーに適した値に設定するため、ここに含めました。

3
Max Vernon

現在、どのエディションとライセンスモードですか？おそらくすべてのコアを使用しているわけではありません。このページのメモを参照してください- http://msdn.Microsoft.com/en-us/library/ms143760.aspx

「Enterprise Edition with Server + Client Access License（CAL）ベースのライセンスは、SQL Serverインスタンスあたり最大20コアに制限されています。」

0
Jeff Sacksteder

このページで説明した問題と同じ問題がありました。電源設定を「バランス」から「高性能」に切り替えると、劇的な違いが生じました-応答時間が2倍以上に。 SSDを使用しているので、エネルギー消費が問題であったとは思いません。

0
tom