Tim*_*per 7 parallel-processing cpu multicore numa
我们刚刚购买了一台32核的Opteron机器,我们获得的加速有点令人失望:超过大约24个线程我们看不到加速(实际上总体上变慢)并且在大约6个线程之后它变得非常线性.
我们的应用程序非常适合线程:我们的工作分为大约170,000个小任务,每个任务可以单独执行,每个任务需要5-10秒.它们都是从大小约为4Gb的相同内存映射文件中读取的.它们偶尔写入它,但每次写入可能有10,000次读取 - 我们只是在170,000个任务的每一个末尾写入一些数据.写入受锁保护.分析表明锁不是问题.线程在非共享对象中使用大量JVM内存,并且它们对共享JVM对象的访问非常少,而且只有一小部分访问涉及写入.
我们在Linux上使用NUMA进行Java编程.我们有128Gb RAM.我们有2个Opteron CPU(型号6274),每个16核.每个CPU有2个NUMA节点.在英特尔四核(即8核)上运行的相同工作几乎线性地扩展到8个线程.
我们已经尝试将只读数据复制到每个线程一个,希望大多数查找可以是NUMA节点的本地查找,但是我们没有观察到它的加速.
有32个线程,'top'显示CPU的74%"us"(用户)和大约23%的"id"(空闲).但是没有睡眠,几乎没有磁盘i/o.有24个线程,我们可以获得83%的CPU使用率.我不确定如何解释'空闲'状态 - 这是否意味着'等待内存控制器'？
我们尝试打开和关闭NUMA(我指的是需要重启的Linux级别设置),并没有看到任何区别.当启用NUMA时,'numastat'仅显示约5%的'分配和访问未命中'(95%的缓存未命中是NUMA节点的本地).[编辑:]但是添加"-XX:+ useNUMA"作为java命令行标志给了我们10%的提升.
我们的一个理论是我们最大化内存控制器,因为我们的应用程序使用了大量的RAM,我们认为有很多缓存未命中.
我们可以做些什么(a)加速我们的程序以接近线性可扩展性,或(b)诊断正在发生的事情？
另外:(c)我如何解释"顶部"结果 - "空闲"是否意味着"在内存控制器上被阻止"？(d)Opteron与Xeon的特性有何不同？
我假设您已经优化了锁，并且同步已降至最低限度。在这种情况下，它仍然在很大程度上取决于您使用哪些库来进行并行编程。
即使没有同步问题，也可能发生的一个问题是内存总线拥塞。这是非常令人讨厌且难以摆脱的。我所能建议的就是以某种方式让你的任务更大并创建更少的任务。这在很大程度上取决于您问题的性质。理想情况下，您希望任务数量与核心/线程数量一样多，但这并不容易（如果可能）实现。
其他有帮助的事情是为 JVM 提供更多堆。这将减少频繁运行垃圾收集器的需要，并加快速度。
“空闲”是否意味着“内存控制器被阻止”
不，你在顶部看不到这一点。我的意思是，如果CPU正在等待内存访问，它将显示为忙碌。如果有空闲期，要么是在等待锁，要么是在等待 IO。