SQL Server-誰でもSUMA、トレースフラグ8048、またはトレースフラグ8015を使用していますか？

最近、SQL Serverスタートアップトレースフラグ8048が含まれ、SQL Server 2008 R2システムでの重大なスピンロック競合の問題が解決されました。

パフォーマンス値がトレースフラグ8048（NUMAノードごとからコアごとにクエリメモリ付与戦略を促進する）、トレースフラグ8015（SQL Serverは物理NUMAを無視する）、またはSUMA（インターリーブされた十分に均一なメモリアクセス、一部のNUMAマシンのBIOSオプション）。

トレースフラグ8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -numa-node-may-need-trace-flag-8048.aspxごとに表示

トレースフラグ8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx

システムのワークロードの詳細、問題のあるシステムからのメトリックの収集、介入後のシステムからのメトリックの収集。

トレースフラグ8048は「修正」でしたが、それが最良の修正でしたか？SQL Serverは、トレースフラグ8015により物理NUMAを無視しても同じことを達成できますか？メモリをインターリーブするようにBIOSを設定して、NUMA動作ではなくSMP動作のSUMA動作をサーバーに残してはどうですか？

平和！tw：@sql_handle

システムについて：-4 hexコアXeon E7540 @ 2.00GHz、ハイパースレッド-128 GB RAM-WS2008R2-MSSQL 2008 R2 SP2-maxdop 6

ワークロードについて：-2つのレポートアプリケーションサーバーから駆動される1000のバッチスケジュール/キューレポート。-3種類のバッチ：毎日、毎週、毎月-SQL Serverへのすべてのレポートアプリケーションサーバー接続は、単一のサービスアカウントとして作成されます-最大レポート同時実行数= 90

問題のあるシステムに関する主な調査結果：-Perfmonから、15秒間隔--システムは95％〜100％のCPU使用率のまま--SQL Serverのバッファーページ検索<10000 /秒

• 待機およびスピンロックDMVから、5分間隔
• • 高いCMEMTHREADウェイターと待機時間
• • 高いSOS_SUSPEND_QUEUEスピンとバックオフ

Bob Dorrのトレースフラグ8048に関するCSSエンジニアブログの投稿は、NUMAノードごとに8コアを超えるシステムがクエリメモリ許可のボトルネックにより同様の症状に陥ることがあることを示しています。トレースフラグ8048は、戦略をNUMAノードごとではなくコアごとに変更します。

介入

-T8048を設定してMSSQLを再起動しました。違いはすぐに明らかになりました。バッファページの検索速度は100万を超え、1秒あたり800万に急上昇しました。以前は24時間で完了できなかった問題のあるバッチワークロードが、4時間未満で完了しました。トレースフラグ8048の修正値の検証の一部として、調査や介入の焦点では​​ない別のバッチワークロードが提出されました（そして、その望ましくない副作用が最小限であることを確認しました）。このレポートバッチは、以前2時間で完了しました。トレースフラグ8048を設定すると、レポートバッチは約20分で完了しました。

ナイトリーETLにもメリットがありました。ETL時間は約60分から40分に短縮されました。

いくつかの場所から情報を集めて、高度なレポートキューイング、ハードウェアスレッドカウントを超える同時レポートカウント、および結合されたすべてのレポートの単一ユーザーアカウントが、ワーカースレッドのプレッシャーによって1つのNUMAノードにプレッシャーをかけると推測します同じユーザーアカウントの次の着信接続要求に対して不利になります。この時点で、次のNUMAノードはほぼ瞬時にいくつかの接続を取得します。各NUMAノードは、クエリメモリ許可のボトルネックを強調する可能性が高くなります。

クエリメモリ許可のためにさらにレーンを開くと、ボトルネックが解消されました。しかし、費用はわかりません。Bob DorrのCSS投稿により、トレースフラグ8048で追加のメモリオーバーヘッドがあることが明らかになりました。単一ページアロケータ領域内のオーバーヘッドは、MSSQL 2008 R2の最大サーバーメモリによって管理されていますか？もしそうなら、システムはバッファプールキャッシュにあるデータベースページの数が少ないと思います。そうでない場合、最大サーバーメモリを下げる必要がありますか？

これは素晴らしい投稿です。

最後の質問に答えるために、あなたの答えは「はい」だと推測します。

そうは言っても、おそらくトレースフラグに頼る前にソフトヌマを追求していたでしょう。numaノードの割り当てについては正しいと思いますが、それが問題の根本にある可能性があります。ソフトヌマを介して、ヌマノードの数（4？）に応じてリクエストをスケールアウトできます-それが正しい数であれば4に、さらにIPアドレスを介して各ホストを特定のヌマノードに割り当てます。それには、ハイパースレッディングを無効にします。組み合わせて、問題はおそらく減少するでしょうが、より少ないスケジューラのコストでそうなります。

別の考えとして、強制的なパラメーター化を見ていきます-負荷がCPUを非常に高く駆動しているという事実は非常に興味深いので、調べる価値があるかもしれません。

最後に、複数の数のノードシステムでは、通常、次のクエリの出力がN秒ごとにテーブルにダンプされます。ワークロードの変更またはトレースフラグが実装されている場合、いくつかの興味深い分析を行います。

SELECT getdate() as poll_time, node_id, node_state_desc, memory_node_id, online_scheduler_count, active_worker_count, avg_load_balance, idle_scheduler_count
FROM sys.dm_os_nodes WITH (NOLOCK) 
WHERE node_state_desc <> N'ONLINE DAC'

そして

SELECT top 10 getdate() as sample_poll, wait_type, count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH','WAITFOR', 'BROKER_TASK_STOP',
'BROKER_RECEIVE_WAITFOR', 'OLEDB','CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT' ) 
GROUP BY wait_type
ORDER BY COUNT (*) DESC