我在3个不同的服务器上运行了7个不同的java守护进程（全部7个）。 java命令行有-Xmx2048m和-Xss1024k。在这3台服务器上，所有21个进程在顶部和顶部都显示不到2.5 GB的VIRT大小。根据守护进程，RES大小从300到1.9 GB不等。
这就是应有的一切。
输入新服务器。更快的CPU，更多的RAM（16 GB而不是8 GB），略微更新的java（旧服务器上为1.6.0_10-b33，新服务器上为1.6.0_31-b04）。两个系统（和JVM）都是64位。
将2个守护进程移动到新服务器。在新服务器上，给定相同的任务，守护进程都消耗了大量CPU（大约是核心价值）并且做得少。 （从旧系统上的5110处理器转移到新系统上的5620处理器。）
几乎是一个额外的CPU使用核心（GC线程??），并为一个守护程序报告5 GB VIRT和2 GB RES，为另一个守护程序报告10.5 GB VIRT和2 GB RES。
任何会导致java忽略的想法（或者如果是这样的话，似乎会忽略）内存限制？
答案 0 :(得分：11)
原来这是一个glibc问题。
我的简短回答是：
导出MALLOC_ARENA_MAX = 1
这减少了过程占地面积（VIRT在顶部）多达5倍。回到CentOS 5中的水平。
最新版本的glibc有一个新功能“每线程内存池”：
http://www.centos.org/docs/5/html/5.4/Technical_Notes/glibc.html
1.71.1日志部分中的最后一项讨论了它（并引用了非公开的错误....）