SQL Server-誰もがSUMA、トレースフラグ8048、またはトレースフラグ8015を使用していますか？
最近、SQL Server 2008 R2システムでの重大なスピンロック競合問題を解決するためのSQL Server起動トレースフラグ8048が含まれています。
パフォーマンス値がトレースフラグ8048（NUMAノードごとからコアごとにクエリメモリ許可戦略を昇格する）、トレースフラグ8015（SQL Serverは物理NUMAを無視する）、またはSUMA（インターリーブされた十分に均一なメモリアクセス（一部のNUMAマシンのBIOSオプション）。
システムワークロードの詳細、問題のあるシステムから収集されたメトリック、および介入後のシステムから収集されたメトリックを次に示します。
トレースフラグ8048は「修正」でしたが、最善の修正でしたか？トレースフラグ8015が原因でSQL Serverが物理NUMAを無視しても同じことを達成できますか？メモリをインターリーブするようにBIOSを設定して、NUMAの動作ではなくSMPを模倣するSUMAの動作をサーバーに残しておくとどうでしょうか。
平和！ tw：@sql_handle
システムについて：-4 hex core 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バッファーページルックアップ<1秒あたり10000
- 待機およびスピンロックDMVから、5分間隔
- 高いCMEMTHREADウェイターと待機時間
- 高いSOS_SUSPEND_QUEUEスピンとバックオフ
トレースフラグ8048に関するBob DorrのCSSエンジニアブログの投稿は、NUMAノードあたり8コアを超えるシステムでは、クエリメモリの付与のボトルネックが原因で同様の症状が発生する可能性があることを示しています。トレースフラグ8048は、戦略をNUMAノードごとではなくコアごとに変更します。
介入
MSSQLは-T8048を指定して再起動されました。違いはすぐに明らかになりました。バッファページのルックアップ率は100万を超え、毎秒800万に急増しました。以前は24時間で完了できなかった問題のあるバッチワークロードは、4時間未満で完了しました。トレースフラグ8048の修正値の検証の一環として、調査または介入の対象ではなかった別のバッチワークロードが送信されました（不要な副作用が最小限であることを確認しています）。このレポートバッチは、以前は2時間で完了していました。トレースフラグ8048を設定すると、レポートバッチは約20分で完了しました。
夜間ETLにもメリットがありました。 ETL時間は約60分から40分に短縮されました。
いくつかの場所から情報をまとめると、高度なレポートキューイング、ハードウェアスレッド数よりも多い同時レポート数、およびすべてのレポートの単一ユーザーアカウントが組み合わされて、ワーカースレッドのプレッシャーが原因になるまで1つのNUMAノードにプレッシャーをかけると推測します同じユーザーアカウントの次の着信接続要求には不満です。その時点で、次のNUMAノードはいくつかの接続をすぐに取得します。各NUMAノードは、クエリメモリ許可のボトルネックにストレスをかける可能性が高くなります。
クエリメモリの付与のために複数のレーンを開くと、ボトルネックが解消されました。しかし、私はコストがわかりません。 Bob DorrのCSS投稿は、トレースフラグ8048で追加のメモリオーバーヘッドがあることを明らかにしています。そのオーバーヘッドは、MSSQL 2008 R2の最大サーバーメモリによって制御される単一ページアロケータ領域内ですか？もしそうなら、私はシステムがバッファプールキャッシュ内の数より少ないデータベースページを持っていると思います。そうでない場合は、サーバーの最大メモリを減らして対応する必要がありますか？
これは素晴らしい投稿です。
あなたの最後の質問に答えるために、私はあなたの答えが「はい」であると推測します。
とはいえ、トレースフラグに頼る前に、やわらかいぬまを追求したでしょう。 numaノードの割り当てについてはあなたが正しいと思います。それが問題の根本にある可能性があります。ソフトnumaを介して、numaノードの数（4？）に応じてリクエストをスケールアウトできます。それが正しい数であれば4になり、さらにIPアドレスを介して各ホストを特定のnumaノードに割り当てます。そのため、ハイパースレッディングを無効にします。組み合わせると、問題はおそらく減少しますが、スケジューラーが少なくなるという犠牲を払って減少します。
別の考えで、私は強制パラメーター化を検討します-負荷が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