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

我们正在将ActivePivot应用程序迁移到新的服务器(4个插槽英特尔至强,512GB内存).部署后,我们启动了应用程序基准测试(这是大型OLAP查询与实时事务并发的组合).测量的性能几乎比我们以前的服务器慢两倍,具有类似的处理器,但是两倍的内核和两倍的内存.

我们调查了两台服务器之间的差异,而大型NUMA架构似乎是一个非统一的内存占用.每个cpu插座物理接近内存的1/4,但远离其余部分…运行我们的应用程序的JVM分配了一个大的全局堆,每个NUMA节点上存在该堆的随机部分.我们的分析是内存访问模式非常随机,cpu内核经常浪费访问远程内存的时间.

我们正在关注利用ActivePivot对NUMA服务器的更多反馈.我们可以配置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个内核,64个内存,256个teraByte.在这种情况下,您可以将JVM进程本身限制到NUMA节点.

在Linux上,您可以使用以下选项(http://linux.die.net/man/8/numactl)为JVM启动前缀：

numactl --cpunodebind=xxx

如果整个服务器专用于一个ActivePivot解决方案,则可以利用ActivePivot分布式体系结构对数据进行分区.如果有4个NUMA节点,您将启动4个JVM托管4个ActivePivot节点,每个节点绑定到其NUMA节点.通过这种部署,查询分布在节点之间,每个节点将在正确的NUMA节点内以最大性能执行其工作份额.