在我们的应用程序中,我们运行在一个双Xeon服务器上,每个处理器的内存配置为12gb,连接两个Xeon的内存总线.出于性能原因,我们希望控制分配大(> 6gb)内存块的位置.以下是简化代码 -
DWORD processorNumber = GetCurrentProcessorNumber();
UCHAR nodeNumber = 255;
GetNumaProcessorNode((UCHAR)processorNumber, &nodeNumber );
// get amount of physical memory available of node.
ULONGLONG availableMemory = MAXLONGLONG;
GetNumaAvailableMemoryNode(nodeNumber, &availableMemory )
// make sure that we don't request too much. Initial limit will be 75% of available memory
_allocateAmt = qMin(requestedMemory, availableMemory * 3 / 4);
// allocate the cached memory region now.
HANDLE handle = (HANDLE)GetCurrentProcess ();
cacheObject = (char*) VirtualAllocExNuma (handle, 0, _allocateAmt,
MEM_COMMIT | MEM_RESERVE ,
PAGE_READWRITE| PAGE_NOCACHE …如何确认主机是否具有NUMA感知功能？在甲骨文的文档说,NUMA意识开始于内核2.6.19,但NUMA手册页说,它与2.6.14介绍.我想确保Java进程开始-XX:+UseNUMA实际上正在利用某些东西.
检查numa_maps,我看到我有它们:
# find /proc -name numa_maps
/proc/1/task/1/numa_maps
/proc/1/numa_maps
/proc/2/task/2/numa_maps
/proc/2/numa_maps
/proc/3/task/3/numa_maps
虽然我的内核落后于Oracle所说的内容:
# uname -sr
Linux 2.6.18-92.el5
我目前在RHEL5.1上使用64位jdk1.6.0_29.
当我们在NUMA系统上工作时,相对于当前NUMA节点,存储器可以是本地的或远程的.为了使内存更加本地化,有一个"第一次触摸"策略(节点绑定策略的默认内存):http: //lse.sourceforge.net/numa/status/description.html
默认内存绑定 用户程序的内存分配在靠近包含运行它们的CPU的节点上是很重要的.因此,默认情况下,来自包含页面错误CPU的节点的内存满足页面错误.因为触摸页面的第一个CPU将是使页面出错的CPU,所以此默认策略称为"第一次触摸".
默认策略称为first-touch.在此策略下,首先触摸(即写入或读取)内存页面的进程会导致该页面在运行该进程的节点中分配.此策略适用于顺序程序和许多并行程序.
还有一些其他非本地政策.还有一个功能要求将内存段显式移动到某个NUMA节点.
但有时候(在单个应用程序的许多线程的上下文中)有一个"下一步触摸"策略是有用的:调用一些函数来"取消绑定"某些内存区域(最多100s MB)和一些数据并重新应用"第一次触摸"此区域上的类似处理程序将在下次触摸(读取或写入)时将页面迁移到访问线程的numa节点.
当许多线程要处理大量数据并且存在对此数据的不同访问模式时(例如,第一阶段 - 通过线程按列分割2D数组;第二阶段 - 按行分割相同数据),此策略非常有用.
从9开始,通过带有MADV_ACCESS_LWP标志的madvice支持这种策略
https://cims.nyu.edu/cgi-systems/man.cgi?section=3C&topic=madvise
MADV_ACCESS_LWP告诉内核接触指定地址范围的下一个LWP将最大程度地访问它,因此内核应该尝试为此范围和LWP分配内存和其他资源.
有(可能是2009年)linux内核的补丁名为"affinity-on-next-touch", http://lwn.net/Articles/332754/(线程),但据我所知它是不被接受到主线,不是它？
还有Lee Schermerhorn的"migrate_on_fault"补丁 http://free.linux.hp.com/~lts/Patches/PageMigration/.
所以,问题是:NUMA在当前的Linux内核或者一些主要的分支中是否有下一步的触摸,比如RedHat linux内核或Oracle linux内核？
我们刚刚购买了一台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的特性有何不同？
我正在使用numactl,使用--physcpubind选项.手册说:
--physcpubind=cpus, -C cpus
Only execute process on cpus. Etc...
假设我有NUMA系统,有3个NUMA节点,每个节点有4个核心.NUMA节点0具有0,1,2,3作为核心编号.NUMA节点1具有4,5,6,7,NUMA节点2具有8,9,10,11.我的问题是让我说我按如下方式运行程序:
export OMP_NUM_THREADS=6
numactl --physcpubind=0,1,4,5,8,9 ./program
即我将用6个线程运行我的程序,我要求它们在CPU核心0,1,4,5,8,9上.例如,如果在程序期间的某个时刻线程0-5被分配了CPU核心0,1,4,5,8,9(setup1).是否有可能在程序执行期间的某个其他时刻线程0可能正在CPU核心9上运行,等等？即CPU内核之间会有线程迁移吗？或者线程唯一地绑定到CPU核心(如在setup1中)？谢谢.
我的问题涉及JVM应用程序可以在多大程度上利用主机的NUMA布局.
我有一个Akka应用程序,其中actor通过将传入数据与已加载到不可变(Scala)对象的"公共"数据相结合来同时处理请求.该应用程序使用许多双核VM在云中很好地扩展,但在单个64核计算机上表现不佳.我认为这是因为公共数据对象驻留在一个NUMA单元中,并且从其他单元同时访问的许多线程对于互连来说太多了.
如果我运行64个单独的JVM应用程序,每个应用程序包含1个actor,那么性能再次良好.一个更温和的方法可能是运行与NUMA单元一样多的JVM应用程序(在我的情况下为8),使主机操作系统有机会将线程和内存保持在一起？
但是有没有更聪明的方法在单个JVM中实现相同的效果？例如,如果我用一个案例类的几个实例替换我的公共数据对象,那么JVM是否有能力将它们放在最佳NUMA单元上？
更新:
我正在使用Oracle JDK 1.7.0_05和Akka 2.1.4
我现在尝试使用UseNUMA和UseParallelGC JVM选项.当使用一个或几个JVM时,似乎都没有对性能降低产生任何重大影响.我也尝试过使用PinnedDispatcher和thre-pool-executor,但没有效果.我不确定配置是否有效,因为启动日志中似乎没有什么不同.
当我为每个工人使用一个JVM(~50)时,最大的改进仍然存在.然而,问题似乎是在FailureDector注册Akka集群JVM之间成功交换"第一个心跳"之前存在很长的延迟(最多几分钟).我怀疑还有其他问题,我还没有发现.我已经不得不增加ulimit -u,因为我达到了默认的最大进程数(1024).
只是为了澄清,我并没有尝试获得大量的消息,只是试图让许多独立的actor同时访问一个不可变的对象.
使用时mbind,可以为给定的映射内存段设置内存策略.
mbind在所有节点上交织段？如果在分配之后但在使用之前完成,则MPOL_INTERLEAVE在所有节点上都将执行我们期望的操作 - 将在所有节点上统一分配内存.
但是,如果段已经被写入并且被分配在例如节点0中,则无法告诉内核在所有NUMA节点上均匀地交织它.
该操作只是变为无操作,因为内核将其解释为" 请将此段放在这组节点上 ".由于我们传递了所有NUMA节点的集合,因此外部没有分配需要移动的内存.
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sched.h>
#include <sys/syscall.h>
#include <numaif.h>
#include <numa.h>
#define N ((1<<29) / sizeof(int))
#define PAGE_SIZE sysconf(_SC_PAGESIZE)
#define PAGE_MASK (~(PAGE_SIZE - 1))
void print_command(char *cmd) {
FILE *fp;
char buf[1024];
if ((fp = popen(cmd, "r")) == NULL) {
perror("popen");
exit(-1);
}
while(fgets(buf, sizeof(buf), fp) != NULL) {
printf("%s", buf);
}
if(pclose(fp)) {
perror("pclose"); …我试图理解这是什么node distances意思numactl --hardware？
在我们的集群上，它输出以下内容
numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 12 13 14 15 16 17
node 0 size: 32143 MB
node 0 free: 188 MB
node 1 cpus: 6 7 8 9 10 11 18 19 20 21 22 23
node 1 size: 32254 MB
node 1 free: 69 MB
node distances:
node 0 1
0: 10 21
1: 21 10
到目前为止，这是我的理解：
考虑以下场景：在 NUMA 计算机上运行的用户进程调用 mmap 在虚拟地址空间中创建新映射。然后它使用 mmap 返回的内存进行处理（存储其数据，...）。现在由于某些原因，用户进程被调度到不同的NUMA节点。用户进程是否可以告诉操作系统在保留数据的同时重新定位已映射的内存（到不同的 NUMA 节点）？