NUMA架构如何影响ActivePivot的性能？

我们正在将ActivePivot应用程序迁移到新服务器（4个插槽Intel Xeon，512GB内存）。部署之后，我们启动了应用程序基准测试（这是大型OLAP查询与实时事务并发的混合）。测量的性能几乎是我们以前的服务器的两倍，它具有类似的处理器，但内核少两倍，内存少两倍。

我们调查了两台服务器之间的差异，看起来大型服务器有一个NUMA架构 （非统一内存访问）。每个CPU套接字在物理上接近内存的1/4，但远离其余部分…运行我们的应用程序的JVM分配一个大的全局堆，每个NUMA节点上有一个随机的堆。我们的分析是内存访问模式非常随机，CPU内核经常浪费时间访问远程内存。

我们正在寻找有关在NUMA服务器上利用ActivePivot的更多反馈。我们可以配置ActivePivot多维数据集或线程池，更改查询，配置操作系统吗？

Peter描述了当前可用的一般JVM选项，以降低NUMA体系结构对性能的影响。为了保持简短，NUMA感知JVM将相对于NUMA节点对堆进行分区，并且当线程创建新对象时，该对象在运行该线程的核心的NUMA节点中分配（如果相同的线程稍后使用）它，对象将在本地内存中）。此外，在压缩堆时，NUMA感知JVM可以避免在节点之间移动大数据块（并减少停止世界事件的长度）。

因此，对于任何NUMA硬件和任何Java应用程序，都应该启用-XX：+ UseNUMA选项。

但对于ActivePivot来说，这并没有多大帮助：ActivePivot是一个内存数据库。有实时更新，但大部分数据驻留在主存储器中，用于应用程序的生命周期。无论JVM选项如何，数据都将在NUMA节点之间分配，执行查询的线程将随机访问内存。知道ActivePivot查询引擎的大多数部分运行速度与内存一样快，NUMA影响尤为明显。

那么如何才能从NUMA硬件上的ActivePivot解决方案中获得最大收益？

当ActivePivot应用程序仅使用一小部分资源时，我们会发现一个简单的解决方案（我们发现在同一服务器上运行多个ActivePivot解决方案时通常会出现这种情况）。例如，ActivePivot解决方案仅使用64个核心中的16个核心，以及TeraByte中的256核心。在这种情况下，您可以将JVM进程本身限制为NUMA节点。

在Linux上，您使用以下选项（ http://linux.die.net/man/8/numactl ）为JVM启动添加前缀：

numactl --cpunodebind=xxx

如果整个服务器专用于一个ActivePivot解决方案，则可以利用ActivePivot分布式架构对数据进行分区。如果有4个NUMA节点，则启动4个承载4个ActivePivot节点的JVM，每个节点绑定到其NUMA节点。通过此部署，查询将在节点之间分配，并且每个节点将在正确的NUMA节点内以最高性能执行其工作共享。

您可以尝试使用-XX:+UseNUMA

http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html

如果这不会产生结果，您可能不得不使用taskset将JVM锁定到特定套接字，并有效地将服务器分成四台机器，每台机器都有一个JVM。

我观察到具有更多套接字的机器对内存的访问速度较慢（甚至是本地内存）以及如何始终为您提供所需的性能提升。