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节点内以最大性能执行其工作份额. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |