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の最大サーバーメモリによって管理されていますか？もしそうなら、システムはバッファプールキャッシュにあるデータベースページの数が少ないと思います。そうでない場合、最大サーバーメモリを下げる必要がありますか？