一、现象说明
最近发现线上机器java 7(openjdk)进程的 VIRT 虚拟内存使用达到了 50G+，如下所示：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3130 tomcat 20 0 9128m 1.4g 6544 S 1.3 9.0 84:14.67 java 31480 tomcat 20 0 7244m 983m 5528 S 0.3 6.2 34:36.95 java 22142 tomcat 20 0 6787m 537m 13m S 0.7 3.4 6:26.70 java 22097 tomcat 20 0 7049m 515m 11m S 0.3 3.2 4:52.39 java 1975 root 20 0 600m 10m 1560 S 0.0 0.1 2:50.42 salt-minion
根据现象猜测:
1. 可能出现内存不足，使用了较多的swap内存；
2. java jdk的版本导致；
3. 由于是虚拟机可能出现物理主机内存不足，导致虚拟机伪内存资源；
二、问题排查
2.1 不管用 xms
首先第一想到的当然使用 java 的-Xmx去限制堆的使用。然而通过top查看,其实并没有使用多少物理内存。
2.2 通过vmstate查看分析
[[email protected] ~]# vmstat -a -S M procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free inact active si so bi bo in cs us sy id wa st 0 0 81 1604 340 3381 0 0 1 1 6 15 0 0 100 0 0
从上面的信息，可以看出来其实资源使用实际很少；
2.3 排查虚拟机资源是否消耗
经过查看vmware，发现上面的虚拟机资源使用并无异常。
三、确定问题原因
经过查阅资料，偶然间发现，这属于一个正常的现象，为什么正常呢？请看下面分析。
glibc 在版本 2.10 引入的 arena 新功能导致。CentOS 6/7 的 glibc 大都是 2.12/ 2.17 了，所以都会有这个问题。这个功能对每个线程都分配一个分配一个本地arena来加速多线程的执行。Java 程序由于自己维护堆的使用，导致调用 glibc 去管理内存的次数较少。更糟的是 Java 8 开始使用 metaspace 原空间取代永久代，而元空间是存放在操作系统本地内存中，那线程一多，每个线程都要使用一点元空间，每个线程都分配一个 arena，每个都64MB，就会导致巨大的虚拟地址被分配。
总结如下：
- VIRT高是因为分配了太多地址空间导致。
- 一般来说不用太在意VIRT太高，因为你有更多的空间可以使用。
- 如果你实在需要控制VIRT的使用，设置环境变量MALLOC_ARENA_MAX，例如hadoop推荐值为4，因为YARN使用VIRT值监控资源使用。
参考链接：https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage?lang=en