不断增长的 Java 进程驻留内存使用 (RSS) [英] Growing resident memory usage (RSS) of Java Process
问题描述
我们最近对生产系统的观察告诉我们，Java 容器的常驻内存使用量在增长.针对这个问题，我们做了一些调查，了解为什么java进程使用pmap等原生工具比Heap + Thread Stacks + Shared Objects + Code Cache +等消耗更多的内存.结果，我们发现一些 64M 内存块(成对)由本地进程(可能使用 malloc/mmap)分配:
Our recent observation on our production system, tells us the resident memory usage of our Java container grows up. Regarding to this problem, we have made some investigations to understand, why java process consumes much more memory than Heap + Thread Stacks + Shared Objects + Code Cache + etc, using some native tools like pmap. As a result of this, we found some 64M memory blocks (in pairs) allocated by native process (probably with malloc/mmap) :
0000000000400000 4K r-x-- /usr/java/jdk1.7.0_17/bin/java
0000000000600000 4K rw--- /usr/java/jdk1.7.0_17/bin/java
0000000001d39000 4108K rw--- [ anon ]
0000000710000000 96000K rw--- [ anon ]
0000000715dc0000 39104K ----- [ anon ]
00000007183f0000 127040K rw--- [ anon ]
0000000720000000 3670016K rw--- [ anon ]
00007fe930000000 62876K rw--- [ anon ]
00007fe933d67000 2660K ----- [ anon ]
00007fe934000000 20232K rw--- [ anon ]
00007fe9353c2000 45304K ----- [ anon ]
00007fe938000000 65512K rw--- [ anon ]
00007fe93bffa000 24K ----- [ anon ]
00007fe940000000 65504K rw--- [ anon ]
00007fe943ff8000 32K ----- [ anon ]
00007fe948000000 61852K rw--- [ anon ]
00007fe94bc67000 3684K ----- [ anon ]
00007fe950000000 64428K rw--- [ anon ]
00007fe953eeb000 1108K ----- [ anon ]
00007fe958000000 42748K rw--- [ anon ]
00007fe95a9bf000 22788K ----- [ anon ]
00007fe960000000 8080K rw--- [ anon ]
00007fe9607e4000 57456K ----- [ anon ]
00007fe968000000 65536K rw--- [ anon ]
00007fe970000000 22388K rw--- [ anon ]
00007fe9715dd000 43148K ----- [ anon ]
00007fe978000000 60972K rw--- [ anon ]
00007fe97bb8b000 4564K ----- [ anon ]
00007fe980000000 65528K rw--- [ anon ]
00007fe983ffe000 8K ----- [ anon ]
00007fe988000000 14080K rw--- [ anon ]
00007fe988dc0000 51456K ----- [ anon ]
00007fe98c000000 12076K rw--- [ anon ]
00007fe98cbcb000 53460K ----- [ anon ]
我将 0000000720000000 3670016K 的行解释为堆空间，我们使用 JVM 参数-Xmx"定义其大小.紧接着，对开始，其总和正好是 64M.我们使用 CentOS 5.10 版(最终版)64 位架构和 JDK 1.7.0_17.
I interpret the line with 0000000720000000 3670016K refers to the heap space, of which size we define using JVM parameter "-Xmx". Right after that, the pairs begin, of which sum is 64M exactly. We are using CentOS release 5.10 (Final) 64-bit arch and JDK 1.7.0_17 .
问题是，那些块是什么?哪个子系统分配这些?
The question is, what are those blocks? Which subsystem does allocate these?
更新:我们不使用 JIT 和/或 JNI 本机代码调用.
Update: We do not use JIT and/or JNI native code invocations.
推荐答案
我遇到了同样的问题.这是 glibc >= 2.10
I ran in to the same problem. This is a known problem with glibc >= 2.10
解决方法是设置这个环境变量<代码>出口 MALLOC_ARENA_MAX=4
The cure is to set this env variable
export MALLOC_ARENA_MAX=4
IBM 关于设置 MALLOC_ARENA_MAX 的文章https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage?lang=en
IBM article about setting MALLOC_ARENA_MAX https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage?lang=en
Google for MALLOC_ARENA_MAX 或在 SO 上搜索以找到大量参考资料.
Google for MALLOC_ARENA_MAX or search for it on SO to find a lot of references.
您可能还想调整其他 malloc 选项以优化已分配内存的低碎片:
You might want to tune also other malloc options to optimize for low fragmentation of allocated memory:
# tune glibc memory allocation, optimize for low fragmentation
# limit the number of arenas
export MALLOC_ARENA_MAX=2
# disable dynamic mmap threshold, see M_MMAP_THRESHOLD in "man mallopt"
export MALLOC_MMAP_THRESHOLD_=131072
export MALLOC_TRIM_THRESHOLD_=131072
export MALLOC_TOP_PAD_=131072
export MALLOC_MMAP_MAX_=65536
这篇关于不断增长的 Java 进程驻留内存使用 (RSS)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
