Peter は、NUMA アーキテクチャのパフォーマンスへの影響を軽減するために現在利用可能な一般的な JVM オプションについて説明しました。簡潔に言うと、NUMA 対応の JVM は NUMA ノードに関してヒープを分割し、スレッドが新しいオブジェクトを作成すると、そのスレッドを実行するコアの NUMA ノードにオブジェクトが割り当てられます (同じスレッドが後で使用する場合)。その場合、オブジェクトはローカル メモリにあります)。また、ヒープを圧縮する場合、NUMA 対応の JVM は、ノード間で大きなデータ チャンクを移動することを回避します (そして、stop-the-world イベントの長さを短縮します)。
したがって、すべての NUMA ハードウェアおよびすべての Java アプリケーションでは、おそらく-XX:+UseNUMAオプションを有効にする必要があります。
しかし、あまり役に立たない ActivePivot の場合: ActivePivot はメモリ内データベースです。リアルタイムの更新がありますが、アプリケーションの存続期間中、データの大部分がメイン メモリに存在します。JVM オプションに関係なく、データは NUMA ノード間で分割され、クエリを実行するスレッドはメモリにランダムにアクセスします。ActivePivot クエリ エンジンのほとんどのセクションが、メモリをフェッチできる限り高速に実行されることがわかっているため、NUMA の影響は特に顕著です。
では、NUMA ハードウェアで ActivePivot ソリューションを最大限に活用するにはどうすればよいでしょうか?
ActivePivot アプリケーションがリソースの一部しか使用しない場合は、簡単な解決策があります (複数の ActivePivot ソリューションが同じサーバーで実行されている場合によくあることです)。たとえば、64 コアのうち 16 コアのみを使用し、テラバイトのうち 256 GB のみを使用する ActivePivot ソリューションです。その場合、JVM プロセス自体を NUMA ノードに制限できます。
Linux では、JVM 起動の前に次のオプション ( http://linux.die.net/man/8/numactl ) を付けます。
numactl --cpunodebind=xxx
サーバー全体が 1 つの ActivePivot ソリューション専用である場合は、ActivePivot 分散アーキテクチャを利用してデータを分割できます。4 つの NUMA ノードがある場合、4 つの ActivePivot ノードをホストする 4 つの JVM を開始し、それぞれがその NUMA ノードにバインドされます。この展開により、クエリはノード間で分散され、各ノードは適切な NUMA ノード内で最大のパフォーマンスで作業のシェアを実行します。