yarn虚拟cpu和虚拟内存
虚拟cpu
虚拟的cpu代码并发数，如果一个container拥有2个vcpu，那么该container就可以真正的在同一时间运行两个线程，而不是靠切时间片而达到的逻辑并发。所以一般虚拟的cpu需要和物理cpu的个数保持一致
yarn的计算单元称为YCUs，其实就是把1个cpu分为n份，通常情况控制在1:1000左右，也就是说一个一核cpu可以被yarn分为1000个左右的YCUs，并在使用yarn的时候，可以配置使用多少YCUs。例如500个YCUs，那么其实得到的大概是1/2个核的cpu。
cpu不像内存一样，内存掌控着程序的生死，而cpu只是决定程序执行的速度。
- 通过控制cpu的功率就可以限制线程的执行速度。比如通过CGgroups限制。
- 分配给一个线程超过1个cpu是没有意思的，纯粹是浪费行为。
- 在一些IO密集型的任务里，就不需要给每个线程分配一个完整的cpu，可以尝试着分配1/2的cpu，利用YCUs就可以做到。
虚拟内存
yarn和虚拟内存的关联
yarn的一些关于虚拟内存的配置
|
key |
默认 |
解释 |
|
yarn.nodemanager.vmem-check-enabled |
true |
是否对app进行虚拟内存监控 |
|
yarn.nodemanager.vmem-pmem-ratio |
5 |
虚拟内存上限系数，乘数是应用物理内存上限 |
yarn默认开启了对应用虚拟内存的检测，虚拟内存可以通过top来看到VIRT，当应用使用的虚拟内存超过了yarn限制的虚拟内存上限，那么yarn会把这个应用杀死。虚拟内存上限的计算公式为：yarn.nodemanager.vmem-pmem-ratio*物理内存。遇到这类虚拟内存超过yarn限制的问题，常见的策略有：
- 关闭yarn对应用虚拟内存的检查
也就是把`yarn.nodemanager.vmem-check-enabled`配置为false
- 调高yarn对应用虚拟内存限制的系数
把` yarn.nodemanager.vmem-pmem-ratio`配置更大一点
- 减少应用对虚拟内存的使用
这块牵扯的内容稍微多一些，先给个结论，修改linux的环境变量`export MALLOC_ARENA_MAX=4`，下面详细解释一下应用的虚拟内存使用
什么是虚拟内存
操作系统将磁盘空间当做内存空间供给程序使用
# 查看某个进程的虚拟内存使用
pmap -x pid
为什么虚拟内存分配了很多
我们知道Linux下glibc的内存管理机制用了一个很奇妙的东西，叫arena。在glibc分配内存的时候，大内存从从中央分配区分配，小内存则在线程创建时，从缓存区分配。为了解决分配内存的性能的问题，就引入了这个叫做arena的memory pool，其原理就是通过为每个线程构建一个arena，来避免多线程同时竞争一个arena。而在64bit系统下面，它的缺省配置为64M。一个进程可以最多有cores*8个arena，假如服务器是4核的，那么最多有4*8=32个arena，也就是32*64 = 2048M内存
查资料发现这是 glibc 在版本 2.10 引入的 arena 新功能导致。CentOS 6/7 的 glibc 大都是 2.12/ 2.17 了，所以都会有这个问题。这个功能对每个线程都分配一个分配一个本地arena来加速多线程的执行。
在 glibc 的 arena.c 中使用的 mmap() 调用就和之前的示例代码类似：
p2 = (char *)mmap(aligned_heap_area, HEAP_MAX_SIZE, PROT_NONE,
MAP_NORESERVE | MAP_ANONYMOUS | MAP_PRIVATE, -1, 0)
之后，只有很小的一部分地址被映射到了物理内存中：
mprotect(p2, size, PROT_READ | PROT_WRITE)
因此在一个多线程程序中，会有相当多的 64MB 的 arena 被分配。这个可以用环境变量 MALLOC_ARENA_MAX 来控制。在64位系统中的默认值为 128，也就是单个进程最多可以申请128个arena。
由于Java 程序由于自己维护堆的使用，导致调用 glibc 去管理内存的次数较少。更糟的是 Java 8 开始使用 metaspace 原空间取代永久代，而元空间是存放在操作系统本地内存中，这就导致线程一多，每个线程都要使用一点元空间，也就是每个线程都分配一个64MB的 arena，导致巨大的虚拟地址被分配。
可以减小MALLOC_ARENA_MAX，比如
export MALLOC_ARENA_MAX=4
参考
https://yq.aliyun.com/articles/227924
https://unix.stackexchange.com/questions/379644/glibc-memory-alloction-arenas-and-debugging
