SQLServerに対するVMwareCPUホットプラグvNUMAの影響

Windows Server2012のESX5とHyper-Vがリリースされ、VMサイズに以前存在していた制限が変更されたとき、より大規模なSQLServerワークロードが仮想化され始めることがすぐにわかりました。私は昨年、16〜32コアのSQL Serverを仮想化していた多くの顧客と協力してきましたが、他のビジネスに合わせた簡素化されたディザスタリカバリ戦略から、新しいハードウェアでの統合と総所有コストの削減まで、さまざまな理由があります。プラットフォーム。 ESX 5+でスケーラビリティが変更された理由の1つは、個々のハードウェアNUMAノードのサイズを超えるワイドゲスト用の仮想NUMA（vNUMA）の導入でした。 vNUMAを使用すると、ゲストVMはハードウェアNUMAトポロジに一致するように最適化され、ゲストオペレーティングシステムと、VM上で実行されているSQL ServerなどのNUMA対応アプリケーションが、まるでNUMAパフォーマンスの最適化を利用できるようになります。物理サーバー上で実行されています。

VMware内では、vNUMAトポロジはハードウェアバージョン8以降で使用可能であり、ゲストのvCPUの数が8を超える場合、デフォルトで構成されます。高度な構成オプションを使用してVMのvNUMAトポロジを手動で構成することもできます。これは、物理NUMAノードが提供できるよりも多くのメモリが割り当てられているが8個以下のvCPUを使用するVMに役立ちます。ほとんどの場合、デフォルトの構成設定は、過去数年間に調べたほとんどのVMで機能しますが、デフォルトのvNUMAトポロジが理想的ではなく、手動構成でいくつかの利点が得られるシナリオもあります。最近、512GBのRAMが割り当てられた32個のvCPU SQL Server VMを備えたクライアントを使用して、vNUMAトポロジが期待どおりではないパフォーマンス調整を行っていました。

この環境のVMホストサーバーは、4つのソケットE5-4650 8コアプロセッサと1TBのRAMであり、それぞれが通常の操作では単一のSQL Server VM専用ですが、障害シナリオで2つのVMを維持するための利用可能な容量があります。このハードウェアレイアウトでは、ソケットごとに1つずつ、合計4つのNUMAノードがあり、予想されるVM構成では、32vCPU構成の場合に4つのvNUMAノードも提示されます。ただし、SQL ServerでDMVを調べているときに見つけたのは、そうではないということでした。

図1-不適切なvNUMA構成

おそらく画像でわかるように、このサーバーのNUMA構成に何か問題があります。 SQLOS内には4つのメモリノードがあり、CPUノードは1つだけで、すべてのvCPUが割り当てられています。正直なところ、これは、SQLOSがインスタンスの起動時に内部構造を構成する方法について私が知っていたすべてに反するため、私がそれを見たときに私を驚かせました。 ErrorLogファイル、パフォーマンスモニター、およびWindowsタスクマネージャーを少し調べた後、SysInternalsからCoreInfoのコピーをダウンロードし、Windowsに報告されているNUMAレイアウトを確認しました。

論理プロセッサからNUMAノードへのマップ：
********************************NUMAノード0

CoreInfo出力は、VMが32個のvCPUを4つの異なるソケットとして提示することを確認しましたが、32個のvCPUすべてをNUMAノード0にグループ化しました。VM上のWindows Server 2012パフォーマンスカウンターを見ると、NUMAノードメモリカウンターグループからわかります。 4つのNUMAメモリノードがOSに提示され、メモリはノード全体に均等に分散されていました。これはすべてSQLOSで見たものと一致し、起動ERRORLOGエントリから、ノードのcpuマスクが使用可能なすべてのCPUをCPUノード0にマスクしていることもわかりましたが、4つのラージページアロケーターが作成されていました。各メモリノード。

この時点で、VM構成に関連するものであると確信していましたが、VMwareESX5以降のクライアントを支援した他のワイドSQLServerVMでこの動作を確認したことがなかったため、具体的に問題が何であるかを特定できませんでした。過去に。使用可能なテストVMサーバーにいくつかの構成変更を加えた後、VM内に表示されているvNUMA構成を修正したのはいずれもありませんでした。 VMwareサポートに連絡した後、テストVMのvCPUホットプラグ機能を無効にして、問題が修正されたかどうかを確認するように求められました。 VMでホットプラグを無効にすると、CoreInfo出力により、VMのプロセッサのvNUMAマッピングが正しいことが確認されました。

論理プロセッサからNUMAノードへのマップ：
******** ————————NUMAノード0
——– ******** ————— --NUMAノード1
—————- ******** ——–NUMAノード2
————————********NUMAノード3

この動作は、2013年10月のVMware KBの記事（VCPUホットプラグが有効になっている場合はvNUMAが無効になっています）に実際に記載されています。これは、vCPUホットプラグが有効になっているSQLServer用の最初のワイドVMでした。 32 vCPU VMに期待する一般的な構成ではありませんが、クライアントで使用されている標準テンプレートの一部であり、SQLServerに影響を及ぼしました。

vNUMAが無効になっている場合の影響

このようにvNUMAを無効にするとワークロードに影響を与える可能性のある影響は多数ありますが、このタイプの構成では特にSQLServerに影響を与える可能性のある2つの特定の問題があります。 1つは、単一のNUMAノードに32個のvCPUが割り当てられており、SQLOSのメモリオブジェクトのデフォルトのパーティション分割がNUMAノードごとであるため、サーバーでCMEMTHREAD待機の累積に問題が発生する可能性があることです。この特定の問題は、MicrosoftのCSSグループのBob Dorrが、NUMAノードごとに8つを超えるCPUを搭載した新しいマシン上のSQL Server2008/2008R2のブログ投稿で文書化されています。クライアントを使用するVMで、CMEMTHREADが2番目に高い待機タイプであることに気付きました。これは私の経験からは異常であり、上記の図1に示すSQLOSNUMA構成を確認することになりました。この場合、トレースフラグは解決策ではありません。VM構成からvCPUホットプラグを削除すると、問題が解決します。

特にパッチが適用されていないバージョンを使用している場合にSQLServerに影響を与える2番目の問題は、SQLOSのNUMAメモリ管理、およびインスタンスの起動後の初期メモリランプアップフェーズ中にSQLOSがアウェイページを追跡および管理する方法に関連しています。この動作は、CSSブログ投稿「HowIt Works：SQL Server（NUMA Local、Foreign and Away MemoryBlocks）」でBobDorrによって文書化されています。基本的に、SQLOSが初期ランプアップ中にローカルノードのメモリ割り当てを試行するときに、返されたメモリアドレスが別のメモリノードからのものである場合、ページは退席中リストに追加され、別のローカルメモリ割り当ての試行が発生し、プロセスは次のように繰り返されます。ローカルメモリの割り当てが成功するか、サーバーのメモリターゲットに到達します。インスタンスメモリの4分の3は、スケジューラのないNUMAノードに存在するため、インスタンスのメモリの初期立ち上げ時にパフォーマンスが低下します。最近の更新により、初期ランプアップ中のメモリ割り当ての動作が変更され、外部メモリを使用して処理を続行する前に、ローカルメモリ割り当てを固定回数だけ試行するようになりました（特定の回数は文書化されていません）。これらの更新は、KB＃2819662、FIX：NUMA環境でのSQLServerのパフォーマンスの問題に記載されています。

概要

8つを超えるvCPUを持つと定義されたワイドVMの場合、WindowsとSQL Serverがコードベース内でNUMA最適化を活用できるように、ハイパーバイザーによってvNUMAをVMに渡すことが望ましいです。その結果、これらの幅の広いVMではvCPUホットプラグ構成を有効にしないでください。これはvNUMAと互換性がなく、仮想化するとSQLServerのパフォーマンスが低下する可能性があるためです。