トレースフラグ8002がオンのSQL Serverプロセッサアフィニティ
SQL Serverでのプロセッサアフィニティの設定 の望ましくない副作用を説明する記事を読んでいます。
私が知るようになったのは、ほとんどの場合、SQL Serverのデフォルト設定が最適に機能することです。これは、プロセッサアフィニティを設定するときに、スケジューラのCPUをバインドするためです。ここにいくつか質問があります：
プロセッサアフィニティのデフォルト設定が最適に機能する場合、なぜプロセッサアフィニティを明示的に設定する必要が生じるのでしょうか。
記事はまた述べています：
トレースフラグ8002をオンにすると、スケジューラはCPUにバインドされなくなります。
トレースフラグ8002が
ONであることは、SQL Serverで使用できるコアの数が少ないことを除いて、デフォルトのProcessor affinity構成と同じであると言っても問題ありませんか？たとえば、32コアプロセッサ（トレースフラグ8002を
ONとして）のプロセッサ親和性を16コアに設定した場合、SQLスレッドが関連付けられているスケジューラは16 coresのみを切り替えますか？プロセッサアフィニティを設定すると、SQL Serverスケジューラが一部のコアを使用するように制限されます。この設定は、.NETアプリケーションなど、CPUを集中的に使用する他のプロセスのコア使用量も制限しますか？
私が言おうとしているのは、32コアCPUの場合、プロセッサアフィニティが16コアに設定されている場合、SQL Serverスケジューラーは16コアしか切り替えられません。はいの場合、.NETアプリケーションなど、CPUを集中的に使用する別のアプリケーションについてはどうでしょうか。 [〜＃〜] sqlos [〜＃〜] ではなくWindows OSに依存するため、.NETアプリには32コアすべてを切り替える自由がありますか？
それは私が想像した単なる仮説のシナリオです。運用シナリオを考えると、同じサーバー上でSSMSとCPUを集中的に使用する.NETアプリケーションを使用する人がいるのではないかと思います。これにより、パフォーマンスが大幅に低下し、他のプロセスのCPU可用性が低下します。私がここで間違っていたら訂正してください。
- ワークロードがプロセッサキャッシュに収まる特定のケースでは、プロセッサアフィニティを設定する必要があります。これはSQL Serverではまれですが、DB内で分析を実行するときに発生する可能性があります。 R付き
- そうだと思います
- いいえ、ありません。ワークロードごとにアフィニティを選択的に設定する必要があります。通常、32コアと言った場合、2つをOS用に予約し、他を分割することができますが、コアとキャッシュを確実に一緒に保つように注意してください。各CPUでコアのサブセットを使用するCPUセットを作成し、クロスキャッシュチャッターでパフォーマンスを殺すことができます。
一般に、必要でないと確信し、基盤となるハードウェア、そのNUMAボードの配置などを十分に理解している場合を除いて、これはお勧めしません。損傷はしませんが、パフォーマンスを著しく低下させる可能性があります。ワークロードを分離する必要がある場合、最新システムのより良いオプションは、99％のユースケースでHyper-Vを使用することです。
アフィニティマスクはとにかく廃止される予定です であり、新しいメソッドはNUMA対応であることにも注意してください。