CPU使用率は外部NUMAアクセスのコストに影響しますか？

シナリオ

1つのNUMAノードごとに4つのソケットを持つSQL Serverがあるとします。各ソケットには4つの物理コアがあります。合計512 GBのメモリがあるため、各NUMAノードには128 GBのRAMがあります。

キーテーブルが最初のNUMAノードにロードされます。

質問

そのテーブルから多くのトラフィックを読み取っていると仮定しましょう。NUMAノードを所有するソケットのすべての物理コアのCPU使用率が100％の場合、他のソケットからの非ローカルNUMAアクセスのコストに悪影響を及ぼしますか？または、その一方で、非ローカルNUMAアクセスのコストは、そのソケットがどれほどビジーであるかに関係ありませんか？

私の質問が理にかなっていることを願っています。明確にならない場合はお知らせください。

バックグラウンド

先週、本番サーバーでデータベースの問題が発生し、処理されたビジネスの一部が他のビジネスよりも大きな影響を受けたようです。1分以上かかる論理読み取りの少ないクエリがありました。全体のCPU使用率を調べたところ、約60％でした。ソケット固有のCPUメトリックは確認しませんでした。I / Oメトリックは平均でした。

多額の質問:-)関係するいくつかの要因の概要を説明します。どのような状況でも、これらの要因やその他の要因はさまざまであり、興味深い結果をもたらします。

申し訳ありませんが、これをもっと短くすることはできませんでした...

1. 累積CPUミリ秒と論理IO
2. SQL Serverの論理メモリノードと物理NUMAノードのアライメント
3. クエリワークスペースのメモリ割り当てにおけるスピンロックの競合
4. スケジューラーへのタスクの割り当て
5. バッファプール内の関連データの配置
6. 物理メモリの配置

1. 累積CPUミリ秒と論理IO

   ワークロードのCPU効率を測定し、スピンロックが発生しやすいケースを探すために、CPU使用率に対する論理IOグラフ（またはperfmon用語「バッファープールページルックアップ」）を使用します。

   ただし、SQL Serverは、ページ検索やスピンロック以外の多くのアクティビティでCPU時間を蓄積します。

   • 計画はコンパイルされ、再コンパイルされます。
   • CLRコードが実行されます。
   • 機能が実行されます。

   他の多くのアクティビティは、ページ検索に反映されることなく、かなりのCPU時間を消費します。

   私が観察するワークロードでは、これらの「非論理IO集中型ですがCPUをゴブリングする」アクティビティの主なものは、ソート/ハッシュアクティビティです。

   それは理にかなっています：非クラスター化インデックスのないハッシュテーブルに対する2つのクエリの不自然な例を考えてみましょう。2つのクエリには同じ結果セットがありますが、結果セットの1つは完全に順序付けられておらず、2番目の結果セットは選択された複数の列によって順序付けられています。2番目のクエリは、バッファプール内の同じ数のページを参照する場合でも、より多くのCPU時間を消費することが予想されます。

   これらの投稿では、ワークスペースメモリの詳細、および付与されたワークスペースの使用量について説明しています。

   • http://sql-sasquatch.blogspot.com/2015/08/sql-server-grantedreservedstolen_4.html

   • http://sql-sasquatch.blogspot.com/2015/08/sql-server-workspace-memory-with-twist.html

   • http://sql-sasquatch.blogspot.com/2015/03/resource-governor-to-restrict-max-query.html

2. SQL Serverの論理メモリノードと物理NUMAノードのアライメント

   SQL Server（NUMA対応の戦略が組み込まれているため）は、デフォルトでサーバー上のNUMAノードごとにSQLOSメモリノードを作成します。メモリ割り当てが大きくなると、各割り当てはSQLOSメモリノードの1つによって制御されます。

   理想的には、SQLOSメモリノードは物理NUMAノードと完全に整合しています。つまり、各SQLOSメモリノードには単一のNUMAノードのメモリが含まれ、他のSQLOSメモリノードには同じNUMAノードのメモリも含まれません。

   ただし、その理想的な状況が常に当てはまるわけではありません。

   次のCSS SQL Server Engineersブログ投稿（Kinの回答にも含まれています）では、SQLOSメモリノードのクロスNUMAノードメモリ割り当ての永続化につながる可能性のある動作について詳しく説明しています。これが発生すると、パフォーマンスへの影響が壊滅的になります。

   • http://blogs.msdn.com/b/psssql/archive/2012/12/13/how-it-works-sql-server-numa-local-foreign-and-away-memory-blocks.aspx

   永続的なクロスNUMAノード参照の特に痛みを伴うケースに対して、いくつかの修正が行われました。これら2つに加えて、おそらく他にも：

   • 修正：SQL Server 2012またはSQL Server 2014での外部ページ処理中にNUMA環境でパフォーマンスの問題が発生する

   • FIX：NUMA環境でのSQL Serverパフォーマンスの問題

3. ワークスペースメモリの割り当て中のスピンロック競合

   ここからが楽しみです。ワークスペースメモリでの並べ替えとハッシュ処理はCPUを消費しますが、bpoolルックアップ番号には反映されないことは既に説明しました。

   スピンロックの競合は、この特定の楽しみの別のレイヤーです。メモリがバッファプールから盗まれ、クエリメモリの許可に対して使用するために割り当てられると、メモリアクセスはスピンロックでシリアル化されます。デフォルトでは、これはNUMAノードレベルでパーティション化されたリソースで行われます。そのため、ワークスペースメモリを使用する同じNUMAノードでのすべてのクエリは、許可に対してメモリを盗むときにスピンロックの競合を引き起こす可能性があります。非常に重要なことに注意してください：これは、「クエリごとに1回」の競合リスクではありません。競合のポイントが実際の許可時にあった場合と同様です。むしろ、メモリがグラントに対して盗まれたとき-そのため、メモリグラントが非常に大きいクエリでは、グラントのほとんどを使用するとスピンロック競合が発生する可能性が高くなります。

   トレースフラグ8048は、コアレベルでリソースをさらに分割することにより、この競合を緩和するという素晴らしい仕事をします。

   Microsoftは、「ソケットごとに8個以上のコアがある場合、トレースフラグ8048を検討する」と述べています。しかし...（実際には、複数のコアがある限り）ソケットあたりのコア数ではなく、単一のNUMAノードで行われている作業の競合の機会の数です。

   接着されたAMDプロセッサ（ソケットあたり12コア、ソケットあたり2 NUMAノード）には、NUMAノードあたり6コアがありました。トレースフラグ8048が有効になるまでスピンロックコンボイで詰まったCPUが4つ（つまり8つのNUMAノード、それぞれ6コア）のシステムを見ました。

   このスピンロックの競合により、4つのvCPUのVMでパフォーマンスが低下するのを見てきました。トレースフラグ8048は、それらのシステムで有効にされたときに想定されていたことを実行しました。

   適切なワークロードを備えた4つのコア周波数最適化CPUがまだ存在することを考慮すると、トレースフラグ8048からもメリットが得られます。

   CMEMTHREAD待機は、トレースフラグ8048が緩和するタイプのスピンロック競合を伴います。ただし、注意事項：CMEMTHREAD待機は、この特定の問題の根本原因ではなく、確証的な症状です。累積CMEMTHREAD待ち時間がかなり短いため、トレースフラグ8048または9024、あるいはその両方が展開で遅延したCMEMTHREAD「待機開始」の高いシステムを見てきました。スピンロックでは、通常、累積待機時間を見るのは間違っています。むしろ、無駄なCPU時間を確認する必要があります。これは主にスピン自体で表され、次に不要なコンテキスト切り替えを表す関連する待機で表されます。

   • 仕組み：CMemThreadとデバッグ

4. スケジューラーへのタスクの割り当て

   NUMAシステムでは、特定のNUMAノードに接続エンドポイントが関連付けられていない場合、接続はNUMAノードに（実際にはそれらに関連付けられたSQLOSスケジューラグループに）ラウンドロビンで配布されます。セッションが並列クエリを実行する場合、単一のNUMAノードのワーカーを使用することを強く好みます。うーん...複雑なクエリが4つのパスに分割され、デフォルトで0 MAXDOPの4 NUMAノードサーバーを検討してください。クエリがMAXDOPワーカースレッドのみを使用した場合でも、NUMAノード上の各論理CPUに4つのワーカースレッドが存在します。ただし、複雑な計画には4つのパスがあります。したがって、NUMAノードの各論理CPUには16個のワーカーを含めることができます。すべて1つのクエリに対してです。

   これが、あるNUMAノードが他の人がローフしている間に一生懸命に動作するのを見ることがある理由です。

   タスクの割り当てには他にもいくつかのニュアンスがあります。ただし、主なポイントは、CPUビジーが必ずしもNUMAノードに均等に分散されるわけではないということです。（bpoolページの挿入（読み取りまたは最初のページの書き込み）が、ワーカーがいるスケジューラに関連付けられたSQLOSメモリノードのbpoolに移動することも理解しておくと便利です。また、盗まれたページは、優先的に「ローカル」SQLOSメモリノードも。

   maxdopを0から8以下にすることは役立つことがわかりました。ワークロードプロファイル（主に、予想される潜在的に長時間実行されるクエリの同時実行数）に応じて、MAXDOP = 2に到達することが保証される場合があります。

   並列処理のコストしきい値を調整することも役立ちます。私が取り組んでいるシステムは、高コストのクエリで消費される傾向があり、50または100未満のプランに遭遇することはめったにありません。

   • 8つのNUMAノードを持つSQL Server PLE

     この投稿では、ワークスペースのメモリと不均等なタスクの分散に関するスピンロック競合の組み合わせについて説明します。参照してください-これらのことは本当にすべて一緒に織ります:-)

   • 40の同時SQL Server並列クエリ+（2ソケット*ソケットあたり10コア）=スピンロックコンボイ

5. bpoolでの関連データの配置

   これは、NUMAサーバーを扱うときに最も直感的だと思う条件です。また、最も一般的には、ワークロードのパフォーマンスにそれほど重要ではありません。

   テーブルがNUMAノード3のbpoolに読み込まれ、後でNUMAノード4のクエリがNUMAノード間ですべてのbpoolルックアップを実行してテーブルをスキャンするとどうなりますか？

   Linchi Sheaは、このパフォーマンスへの影響について素晴らしい投稿をしています：

   • http://sqlblog.com/blogs/linchi_shea/archive/2012/01/30/performance-impact-the-cost-of-numa-remote-memory-access.aspx

   NUMAノード間でメモリにアクセスすると、少量の追加メモリレイテンシが発生します。最適なパフォーマンスを得るために、追加のベースメモリレイテンシを排除する必要があるワークロードがあると確信しています。これは、使用しているシステムでは問題ではありません。

   ただし、クロスノードアクセスは、飽和する可能性のある別の転送ポイントももたらします。NUMAノード間のメモリ帯域幅が飽和するほど多くのアクティビティがある場合、ノード間のメモリ遅延が増加します。同じ作業には、追加のCPUサイクルが必要です。

   繰り返しますが、メモリ帯域幅が重要な考慮事項であるようなワークロードがあると確信しています。しかし、私のシステムでは、私がリストしている他の考慮事項がより重要です。

6. 物理メモリの配置

   これはめったにありませんが、重要な場合は本当に重要です。ほとんどのサーバーでは、メモリのインストールはほぼ自然にNUMAノード間でバランスを取ります。ただし、場合によっては、ノード間でメモリのバランスを取るために特別な注意が必要です。一部のシステムでは、メモリがバランスされないような方法でスロットに入れられた場合、パフォーマンスが完全に損なわれる可能性があります。ただし、これは設定して忘れるだけです。最初の本当に忙しい日の後とは対照的に、数ヶ月の生産サービスの後、このような問題を発見することは非常にまれです:-)

ビッグフィニッシュ！

他の誰かが、おそらく時代遅れの統計のために計画の選択が悪いと、あなたが見た症状を引き起こす可能性があると指摘しました。私の経験ではそうではありませんでした。計画が不適切だと、クエリが予想よりも長くかかる可能性がありますが、通常は必要以上の論理IOが実行されているためです。または、tempdbへの流出が原因です。サーバーを観察すると、tempdbへの大量の流出が明らかになるはずです。CPUが高いというよりは、流出に関連するディスク書き込みの測定可能な待機時間が予想されます。

代わりに、観察した状況がNUMA関連である場合、上記に列挙した要因の組み合わせであると予想されます。

1. ワークスペースメモリの使用（論理IOカウントには表示されません）

2. 永続的な外部メモリの状態が原因でクロスNUMAノードである可能性があります（その場合は、関連する修正を探してください）

3. また、グラントに対して割り当てが行われるたびにNUMAノード内でスピンロックの競合が発生する可能性があります（T8048で修正）

4. また、他の並列クエリワーカーによって過負荷になった論理CPU上のワーカーによって実行される可能性があります（必要に応じてmaxdopや並列処理のコストしきい値を調整します）

（（sysinternalユーティリティ）出力で質問を更新してcoreinfo -v、CPU /ソケットおよびNUMA分布のより良いコンテキストを取得してください）

全体のCPU使用率を調べたところ、約60％でした。ソケット固有のCPUメトリックは確認しませんでした。I / Oメトリックは平均でした。

あなたは間違った木でbarえているように思えます。SQL ServerはNUMA認識しています。クロスNUMAメモリアクセスを行うことによるパフォーマンスの低下ははるかに小さくなります。このクエリを使用しNUMAて、所有しているノードの数と、どのCPUとコアがどのノードに割り当てられているかを確認することもできますNUMA。

SELECT parent_node_id, scheduler_id, cpu_id
FROM sys.dm_os_schedulers WITH (NOLOCK) 
WHERE [status] = N'VISIBLE ONLINE';

またはちょうどいくつNUMA：

select COUNT(distinct Parent_node_id)
from sys.dm_os_schedulers
where [STATUS] = 'VISIBLE ONLINE'
    and Parent_node_ID < 64

1分以上かかる論理読み取りの少ないクエリがありました。

これは、通常、古い統計のために不正なクエリプランが生成された場合に発生します。統計が更新され、インデックスが適切に最適化されていることを確認してください。

また、ワーカースレッドの枯渇を回避するには、MAXDOPをより適切な値に設定する必要があります。

cost threshold of parallelismデフォルトの5から45などの適切な開始値に設定し、その値を監視して、環境に従って調整します。

アドホッククエリを多数実行している場合は、オン（1に設定）optimize for ad hoc workloadsをオンにして、プランキャッシュの肥大化を防ぎます。

注意して使用：NUMAノードごとに8個以上のCPUが搭載された新しいマシンでSQL Server 2008/2008 R2を実行している場合、T8048を使用できます。SQLServer 2012または2014の場合は修正プログラムがあります。

データベースサーバーインスタンスに関する待機統計情報の収集を開始することを強くお勧めします。

参照：仕組み：SQL Server（NUMA Local、Foreign and Away Memory Blocks）

純粋にハードウェアの観点から、Nehalemアーキテクチャ以降のメインメモリの管理は、統合メモリコントローラによる管理です。これは、CPUダイの「非コア」部分であり、実際のコアが存在する部分とは別です。メモリは各CPUに効果的に「配線」されているため、外部メモリアクセスAFAIKはクイックパス相互接続（再びNehalem以降）を介して行われるため、ローカルNUMAノードでのCPUコアの飽和はそのメモリへのリモートアクセスに影響を与えません。

このリンクは役に立つかもしれません：

http://cs.nyu.edu/~lerner/spring10/projects/NUMA.pdf

クリス