SQL Server 2016プロダクションサーバーの1つでsp_blitzを実行したところ、コアの数が奇数のCPUがあることがわかりました。詳細なメッセージは、これが本当に悪いNUMA構成であることを示しています。
SQL Server 2016は、8コアを超える物理プロセッサを検出した場合、自動ソフトNUMAを使用します。私たちの特定のサーバーには、ソケットあたり10個のCPUを備えた2つのソケットがあります。
SQL Serverエラーログの起動メッセージは次のことを示しています。
SQL Serverが8個を超える物理コアを持つハードウェアNUMAノードを検出したため、自動ソフトNUMAが有効になりました。
その結果、SQL Serverは、それぞれ5つのコアを持つ4つの論理NUMAノードを作成しました。
これはパフォーマンスの問題ですか?
MAXDOP = 4を使用しています。
ここで並列処理は問題ですか?
「パフォーマンスに問題はありますか?」というご質問にはお答えできません。あなただけがそれに答えることができます。本番環境で許容できるパフォーマンスを得ていますか?自動ソフトNUMAが有効になっている10 CPUの4つのソケットで許容可能なパフォーマンスが得られる本番システムを知っているので、奇妙なソフトNUMAノードで許容可能なパフォーマンスニーズを得るのは不可能ではありません。スケジューラーの数。
NUMA構成を変更することでパフォーマンスが向上すると思われる場合は、テストすることを検討してください。私が知る限り、すべては実際にワークロードに依存します。自動ソフトNUMAを保持するか、自動ソフトNUMAを無効にするか、またはレジストリを変更してCPUのアフィニティを解除して手動構成を試行するか、手動ソフトNUMAを使用するか、3つの選択肢があります。すぐ下にすべての詳細があるかどうかはわかりませんが、構成を変更するとSQL Server内でどのような変更が行われるかについての情報が役立つ場合があります。
レイジーライターの数は物理NUMAノードの数によって決定されるため、ソフトNUMAは変更しません。 SQL Server 2016では最大4つのトランザクションログライターを使用でき、SQLサーバー内のNUMAノードごとに1つです。これらのトランザクションログライターは、NUMAノード全体に均等に分散されることはありません。必要に応じて、CPU 1、2、3、および4に割り当てられます。論理NUMAノードごとに1つのリソースモニターがあります。論理NUMAノードごとに1 I/O完了スレッド もあると思いますが、具体的には確認していないため、制限があるかどうかはわかりません。
いくつかの設定例を参考にするとよいでしょう。自動ソフトNUMAを無効にするとします。その構成では、SQL Serverに10スケジューラの2つの論理NUMAノード、2つのリソースモニター、2つのレイジーライター、2つのI/O完了スレッド、および2つのトランザクションログライターがあります。 sp_blitz
の結果は表示されなくなります。
次に、自動ソフトNUMAを有効にするとします。その構成では、SQL Serverに5つのスケジューラーを持つ4つの論理NUMAノード、4つのリソースモニター、2つのレイジーライター、4つのI/O完了スレッド、4つのトランザクションログライターがあります。
手動のソフトNUMAを使用すると、ソケットごとに2つのスケジューラ、4つのスケジューラ、および4つのスケジューラの3つのソフトNUMAノードを作成できます。それもsp_blitz
の発見を回避します。ソケットごとに2つのCPUをSQL Serverから見えないようにすることもできます。その場合、ソケットごとに8つのスケジューラがあり、自動ソフトNUMAは適用されません。どちらも私にはかなり奇妙な構成のように聞こえます。
では、これらの構成のどれがワークロードに最適ですか? 2つではなく4つのトランザクションログライターを使用すると、ワークロードにメリットがありますか? 2つではなく4つのリソースモニターを使用すると、ワークロードが損なわれますか?何も思いつきません。あなたができることはそれをベンチマークすることだけです。自動ソフトNUMAがパフォーマンスに悪影響を与える可能性がある場合について、Microsoftから情報を見つけることができませんでした。彼らの 観点 は、一般にパフォーマンスとスケーラビリティを向上させ、パフォーマンスの問題が発生しない限りそのままにしておくようです。 IMOが5つのスケジューラーの4つのソフトNUMAノードにMAXDOP 4クエリを送信することは、私にとってまったく問題に聞こえません。