CALライセンスに基づくSQLServer2012EnterpriseEditionのパフォーマンスの問題

SQLServer2012では多数のライセンス変更が導入されました。最も重要なのは、EnterpriseEditionのソケットベースのライセンスからコアベースのライセンスへの移行でした。この変更でマイクロソフトが直面した課題の1つは、SQLServer2012より前のEnterpriseEditionでServer+CALベースのライセンスを使用していたお客様に移行パスを提供することでした。ソフトウェアアシュアランスのお客様は、SQL Server 2012 Enterprise Editionにアップグレードしても、引き続きServerを使用できます。 + CALライセンス（「祖父母」とも呼ばれます）。ただし、SQL Server 2012ライセンスガイドに記載されているように、20個の論理プロセッサに制限されています。このライセンスは、Enterprise Server + CALライセンスの対象となるVMの制限が4つであるVMにも適用されますが、SQLServer2012仮想化ライセンスガイドに記載されているのと同じ20の論理プロセッサ制限があります。

ライセンスガイドに記載されているにもかかわらず、多くの人が20個の論理プロセッサの制限に気をとられています。

インスタンスの起動時にERRORLOGファイルにエントリが作成され、論理プロセッサの数と20プロセッサの制限が適用されていることが指定されます。

SQLServerがServer+CALを使用する20の論理プロセッサ制限の下で適用するデフォルト構成では、最初の20のスケジューラーはVISIBLE ONLINEであり、残りのスケジューラーはVISIBLEOFFLINEです。 その結果、NUMAノードスケジューラの不均衡が原因で、インスタンスのパフォーマンスの問題が発生する可能性があります。 これを実証するために、2つのソケットとIntel Xeon E5-2670プロセッサがインストールされ、それぞれ8コアとハイパースレッディングが有効になっているDell R720テストサーバー上にVMを作成し、Windows Server 2012DatacenterEditionで利用可能な合計32の論理プロセッサを提供しました。 VMは、2つのvNUMAノードに割り当てられた16の仮想プロセッサを備えた32の仮想CPUを持つように構成されました。

図1-vNUMA設定

Enterprise Server +CALライセンスモデルのSQLServerでは、これにより、次のようなスケジューラ構成が作成されます。

 SELECT parent_node_id、[status]、scheduler_id、[cpu_id]、is_idle、current_tasks_count、runnable_tasks_count、active_workers_count、load_factorFROM sys.dm_os_schedulers; 

図2– Enterprise Server+CALでのスケジューラの割り当て>

ご覧のとおり、最初のNUMAノードの16個の論理プロセッサすべてと、2番目のNUMAノードの4個の論理プロセッサのみがインスタンスによって使用されています。これにより、2つのNUMAノード間でスケジューラの大幅な不均衡が発生し、負荷がかかった状態で重大なパフォーマンスの問題が発生する可能性があります。これを実証するために、AdventureWorks Books Onlineワークロードを実行している300の接続をインスタンスに対してスピンアップし、次のクエリを使用して、インスタンス内のVISIBLEONLINEスケジューラーのスケジューラー情報をキャプチャしました。

 SELECT parent_node_id、scheduler_id、[cpu_id]、is_idle、current_tasks_count、runnable_tasks_count、active_workers_count、load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VISIBLE ONLINE'; 

負荷がかかった状態でのこのクエリの出力例を以下の図3に示します。

図3– Enterprise Server+CALで負荷がかかっているスケジューラー

この症状は、SQL SentryPerformanceAdvisorなどの監視ツールでも視覚的に確認できます。

図4– SQL SentryPerformanceAdvisorに表示されるNUMAの不均衡

この情報は、重大な不均衡とパフォーマンスが結果として影響を受けることを示しています。これは、2番目のNUMAノードの4つのスケジューラーの実行可能タスク数で明らかです。これは、最初のNUMAノードのスケジューラーの3〜4倍のサイズです。では、問題は正確には何であり、なぜこれが発生するのですか？

一見、これはSQL Serverのバグだと思われるかもしれませんが、そうではありません。これは設計上発生するものですが、20個の論理プロセッサの制限が最初に実装されたときにこのシナリオが予期されていたとは思えません。 NUMAベースのシステムでは、新しい接続がラウンドロビン方式でNUMAノードに割り当てられ、NUMAノード内で負荷に基づいて接続がスケジューラーに割り当てられます。このデータの表示方法を変更し、parent_node_idに基づいてデータを集約すると、タスクが実際にNUMAノード間でバランスが取れていることがわかります。これを行うには、次のクエリを使用します。その出力を図5に示します。

 SELECT parent_node_id、SUM（current_tasks_count）AS current_tasks_count、SUM（runnable_tasks_count）AS runnable_tasks_count、SUM（active_workers_count）AS active_workers_count、AVG（load_factor）AS avg_load_factorFROM sys.dm_os_schedulersWHER / pre> 

  
 図5–NUMAノードのラウンドロビンバランス 
 

 この動作は、Books Online for SQL Server（http://msdn.microsoft.com/en-us/library/ms180954(v=sql.105).aspx）に記載されています。 SQLOS、SQL Server、およびハードウェアについて私が知っていることを知っているので、これは理にかなっています。 Server+CALライセンスを使用するSQLServer2012 Enterprise Editionの20の論理プロセッサ制限の前は、SQLServerで実稼働サーバーのNUMAノード間でスケジューラーの不均衡が発生することはまれなシナリオでした。この特定の場合の問題の1つは、仮想NUMAがVMに渡される方法です。物理ハードウェアにまったく同じインストールを実行すると、ハイパースレッドによって提示される追加の論理プロセッサがSQLによって区別可能であり、無料であるため、すべてのスケジューラをオンラインで表示できます。
 

 つまり、（a）仮想マシンではなく、（b）プロセッサがIntelであり、（c）ハイパースレッディングが有効になっている場合、20論理プロセッサの制限により、実際には40のスケジューラがオンラインになります。 
 

 したがって、このメッセージはエラーログに表示されます：
 日付2012年11月14日午後10時36分18秒
ログSQLServer（現在– 2012年11月14日午後10時36分00秒）
ソースサーバー
メッセージ
 SQLサーバーは、ソケットあたり8コア、ソケットあたり16論理プロセッサ、合計32論理プロセッサの2つのソケットを検出しました。 SQLServerライセンスに基づく32個の論理プロセッサを使用します。これは情報メッセージです。ユーザーの操作は必要ありません。 

 また、上記と同じクエリを実行すると、32個のプロセッサすべてがオンラインで表示されます。
 
 SELECT parent_node_id、[status]、scheduler_id、[cpu_id]、is_idle、current_tasks_count、runnable_tasks_count、active_workers_count、load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VISIBLE ONLINE'; 
 

  
 図6–物理ハードウェアでの同じ構成 
 

 この場合、論理プロセッサは32個しかないため、20（まあ、40）のコア制限はまったく影響を与えず、作業はすべてのコアに均等に分散されます。
 

 20プロセッサの制限がスケジューラのNUMAバランスに影響を与えるシナリオでは、ALTER SERVER CONFIGURATIONを使用して、各NUMAノードのVISIBLEONLINEスケジューラの数のバランスをとるためにサーバー構成を手動で変更できます。 。提供されているVMの例では、次のコマンドにより、各NUMAノードの最初の10個の論理プロセッサがVISIBLEONLINEに構成されます。
 
 ALTER SERVER CONFIGURATIONSET PROCESS AFFINITY CPU =0〜9、16〜25; 
 

 この新しい構成では、300セッションの同じワークロードとAdventureWorks Books Onlineワークロードを実行することで、負荷の不均衡が発生しなくなったことがわかります。
 

  
 図7–手動構成で復元されたバランス 
 

 また、SQL Sentry Performance Advisorを使用すると、CPU負荷が両方のNUMAノードに均等に分散されていることがわかります。
 

  
 図8– SQL SentryPerformanceAdvisorに表示されるNUMAバランス 
 

 この問題は、VMと仮想CPUがOSに提示される方法に厳密に限定されません。物理ハードウェアでこの問題が発生する可能性もあります。たとえば、4つのソケットと1つのソケットあたり8つのコアを備えた古いDell R910や、2つのソケットと1つのソケットあたり16のコアを備えたAMD Opteron 6200 Interlagosベースのサーバーでさえ、それぞれ8つのコアを持つ4つのNUMAノードとして表示されます。これらの構成のいずれかでは、プロセスの不均衡により、NUMAノードの1つが完全にオフラインになる可能性もあります。その結果、そのノードからのメモリがオンラインノード全体に分散され、外部メモリアクセスの問題が発生するなど、他の副作用もパフォーマンスを低下させる可能性があります。
 
概要
 

 Server+CALのEnterpriseEditionライセンスを使用するSQLServer2012の既定の構成は、SQLServerに存在する可能性のあるすべてのNUMA構成では理想的ではありません。 Enterprise Server + CALライセンスを使用している場合は常に、NUMAノードごとのNUMA構成とスケジューラのステータスを確認して、SQLServerが最適なパフォーマンスで構成されていることを確認する必要があります。この問題は、すべてのスケジューラーがライセンスされており、オンラインで表示されるため、コアベースのライセンスでは発生しません。