web-dev-qa-db-ja.com

SQL Server 2008 R2クラスターインスタンスに特定のプロセッサを割り当てるのは悪いことですか？

パッシブノードとアクティブノードを備えたSQL Server 2008 R2フェールオーバークラスターがあります。サーバーは物理的に同一です。 SQL Serverの2つのインスタンスがあり、1つは最初の3つのNUMAノードのすべてのCPUを使用するように設定され、もう1つは4番目のNUMAノードのすべてのCPUを使用するように設定されています。

これはフェイルオーバーが発生した場合でも問題なく機能しているようですが、これは悪い考えですか？

パッシブサーバーに多くのプロセッサが搭載されていない場合、フェールオーバーではどうなりますか？

sql-serversql-server-2008-r2configurationclusteringcpu
3
influent

私はそれが悪い考えだとは言いませんが、問題が原因であることが確実にわかっていない限り、SQLサーバーでのCPUアフィニティ触れないこと CPUアフィニティを常に好んでいます過度コンテキスト切り替え（これも実際の問題ではなく、単なる症状の場合があります）。

これはフェイルオーバーが発生した場合でも問題なく動作しているようですが、これは悪い考えですか？

アフィニティを強制するとは、スケジューラ間でプロセスを移動するSQLサーバーの機能を奪うことを意味します。

以下の例を考えてみます：（sysinternalsからのcoreinfoを使用）2ソケット、12 CPU（ハイパースレッディングが有効な24論理CPU）、2 NUMA Node machine、12ノードCPUを取得.

Logical to Physical Processor Map:
**----------------------  Physical Processor 0 (Hyperthreaded)
--**--------------------  Physical Processor 1 (Hyperthreaded)
----**------------------  Physical Processor 2 (Hyperthreaded)
------**----------------  Physical Processor 3 (Hyperthreaded)
--------**--------------  Physical Processor 4 (Hyperthreaded)
----------**------------  Physical Processor 5 (Hyperthreaded)
------------**----------  Physical Processor 6 (Hyperthreaded)
--------------**--------  Physical Processor 7 (Hyperthreaded)
----------------**------  Physical Processor 8 (Hyperthreaded)
------------------**----  Physical Processor 9 (Hyperthreaded)
--------------------**--  Physical Processor 10 (Hyperthreaded)
----------------------**  Physical Processor 11 (Hyperthreaded)

Logical Processor to Socket Map:
************------------  Socket 0
------------************  Socket 1

Logical Processor to NUMA Node Map:
************------------  NUMA Node 0
------------************  NUMA Node 1

スケジューラはコアにバインドされておらず、SQL Serverは独自のスレッドスケジューリングを行うことに注意してください。何らかの理由で、SQL以外のプロセスがスケジューラ1でスレッドを実行しているCPU 1を使い果たした場合、SQLサーバーはそのスケジューラを使用可能なCPUに配置することができます。 CPU 4. SQL Serverには、スレッドをCPU間で移動する独自のロードバランサーがあります。

プロセッサアフィニティを設定する場合、SQLサーバーからスケジューラを切り替える機能を削除します。したがって、スケジューラ1はCPU 1にバインドされており、そこでのみ実行する必要があります。

私の本の図書館からの抜粋...

SQL Server Professional内部およびトラブルシューティングブックから：

ソフトNUMAの一般的な用途の1つは、SQLサーバーが、非常に異なるクエリ要件を持ついくつかの異なるユーザーグループを持つアプリケーションをホストしている場合です。ソフトNUMA用に理論上の16プロセッササーバーを構成し、2×4 CPUノードと1つの8 CPUノードを3番目のNUMAノードに割り当てた後、3つのノードの接続アフィニティを異なるポートに構成し、接続を変更します。ワークロードの各クラスの設定。ワークロードAは、最初のNUMAノードに接続するポートxに「アフィニティ化」されます。ワークロードBは2番目のNUMAノードに接続するポートyに、他のすべてのワークロードは3番目のNUMAノードに接続するように設定されているポートzにそれぞれ割り当てられます。

Microsoft SQL Server 2008 Internalsブックから：

状況によっては利用可能なCPUの数を制限したいが、特定のスケジューラを単一のCPUにバインドしない —たとえば、サーバー統合にマルチCPUマシンを使用している場合。 8つのSQL Serverインスタンスを実行している64プロセッサマシンがあり、各インスタンスで8つのプロセッサを使用するとします。各インスタンスには、64プロセッサの異なるサブセットを指定する異なるアフィニティマスクがあるため、アフィニティマスク値が255（0xFF）、65280（0xFF00）、16711680（0xFF0000）、および4278190080（0xFF000000）になる場合があります。アフィニティマスクが設定されているため、各インスタンスにはスケジューラとCPUのハードバインディングがあります。 CPUの数を制限したいが、特定のスケジューラを特定のCPUで実行するように制限しない場合は、SQL Serverをtrace fl ag 8002で起動できます。これにより、CPUをインスタンスにマップできますが、インスタンス内では、スケジューラーはCPUにバインドされません。

サーバーでSQLインスタンスが使用するCPUを制限する場合は、 代わりにWindowsシステムリソースマネージャー を使用します。

として常にTEST、TESTおよびTEST「CPUアフィニティ」を使用する場合、重大なパフォーマンスの問題を回避するためのワークロード全体。

提案：デフォルトのままにします-間違えたように、事態は悪化し、トラブルシューティングはより困難になります。

パッシブサーバーに多くのプロセッサが搭載されていない場合、フェールオーバーではどうなりますか？

NUMAノードスケジューラの不均衡が原因で、インスタンスでパフォーマンスの問題が発生する可能性があります

参照：

7
Kin Shah