サーバーでNUMAが有効になっているかどうかを確認するにはどうすればよいですか？
上司は、HP DL320 G5でNUMAが有効になっているかどうかを知りたがっています。インターネットを調べてみましたが、特定の情報が見つかりません。
このサーバーがNUMAアプリケーションの実行に適しているかどうか、誰もがすぐにわかるでしょうか？
OpteronsとNelahem（55xx以降）のXeonにはNUMAアーキテクチャがあります。各ソケットには独自のメモリバスがあり、ソケット間にリンクがあります。このリンクは、OpteronシステムではHypertransport、XeonsではQuickpathと呼ばれます。 G5はネラヘムよりも古く、NUMAアーキテクチャではない古いフロントサイドバスを使用しています。
Opteronsおよび35xx/55xx以降のXeonは、純粋なNUMAアドレッシングモードを使用できます。このモードでは、各ソケットのメモリは、物理アドレス空間の連続したセクションに存在します。 NUMA対応のアプリケーション（プロセッサアフィニティのサポートなど）を実行する場合は、システムをこのモードで実行するように設定できます。
このタイプのシステムには、ソケット間で個別の4Kページが交互に表示されるレガシーモードもあり、メモリアクセスはソケット間で細かく混合されます。すべてのメモリアクセスの半分がHypertransportバスを経由して他のソケット（Xeonの場合はQuickpath）に到達する必要があるため、これにはわずかなパフォーマンスオーバーヘッドがあります。ただし、ほとんどのアクセスはキャッシュされるため、パフォーマンスのオーバーヘッドは比較的小さくなります。
このモードを使用すると、システムはNUMA対応でないアプリケーションを効率的に実行できます。これは通常、システムが起動するデフォルトのモードです。通常、これはBIOSで構成できます。
G5はフロントサイドバスアーキテクチャを備えているため、NUMAモードでは実行できません。 FSBは、メモリとすべてのプロセッサソケットによって共有される単一のバスであるため、uniformメモリアクセス特性を持ち、つまり、NUMAではありません。NUMAアーキテクチャに依存するwintelまたはlintelアプリケーションについては知りません。アプリケーションはNUMAを必要としないが、存在する場合はサポートする可能性があります。おそらく古いG5システムでもアプリケーションを実行できます。これが適切かどうかは、アプリケーションと達成したいことによって異なります。
アプリケーションでのNUMAサポート
一部のアプリケーション（SQL Serverは一例です）は、非ローカルアクセスのペナルティを最小限に抑えるために、メモリ、I/O使用率、およびスケジューリングを最適化することで、パフォーマンス上の大きな利点を実現できます。アプリケーションにNUMAサポートを実装するには、オペレーティングシステムから次のようなサポート機能を利用できる必要があります。
スケジューラアフィニティ：スレッドは、1つまたはグループのプロセッサでスケジュールすることを優先するプールに配置できます。 NUMAは単一のメモリバス上に複数のプロセッサを搭載できることに注意してください。マルチコアOpteronまたはXeonの場合、単一のダイ上のコアはすべて同じバスを共有します。これにより、スレッドはローカルメモリを要求したり、CPUプールに対してローカルなメモリプールを使用したりできます。また、スレッドがローカルCPUに保持されている場合、スレッドがスケジュールされているため、キャッシュのスラッシングが最小限に抑えられます。ワーキングセットは、その特定のコアを使用するスレッドのワーキングセットにすぎません。
メモリアフィニティ：スレッドはメモリを要求し、ローカルのメモリからソケットに対して使用可能である必要があることを指定できます。同じバスでメモリとCPUの使用を維持すると、非ローカルメモリアクセスのオーバーヘッドが最小限に抑えられます。最新のNUMAシステムではオーバーヘッドはそれほど大きくありませんが、初期のシーケントギアなどの古いシステムでは、非ローカルアクセスがはるかに遅くなりました。
I/Oアフィニティ：周辺バスをローカルCPUに関連付けることができるため、I/Oに近いプロセッサでI/O処理をスケジュールできます。ほとんどのNUMAシステムには複数のI/Oバスがあるため、割り込みハンドラーとローカルメモリへのDMA=をスケジュールすると、I/Oパフォーマンスにいくつかの利点があります。
最初のNUMA Xeonは55xxシリーズでしたが、G5では使用できません。