PID USER PR NI VIRT RES SHR S %cpu %MEM TIME+ COMMAND 12663 test 20 0 8378m 6.0g 4492 S 43 8.4 162:29.95 java
如你所见,我们有6Gb的常驻内存.现在有趣的部分是:使用这些参数执行该过程:@H_404_5@
> -Xmx2048m
> -Xms2048m
> -XX:NewSize = 512m
> -XX:MaxDirectMemorySize = 256m
> ……其他一些GC和东西@H_404_5@
看看这些设置和实际内存使用情况,我们偶然发现我们期望这个过程使用的内容与实际使用内容的区别.@H_404_5@
通常我们的内存问题通过分析堆转储来解决,但在这种情况下,我们的内存被用在堆外的某个地方.@H_404_5@
问题:
尝试找出如此高内存使用率的原因是什么?
哪些工具可以帮助我们确定在该过程中使用内存的内容?@H_404_5@
编辑0@H_404_5@
看起来这不是一个堆相关的问题,因为我们仍然有相当大的空间:@H_404_5@
jmap -heap 12663
结果(编辑以节省空间)@H_404_5@
Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 2147483648 (2048.0MB) NewSize = 536870912 (512.0MB) MaxNewSize = 536870912 (512.0MB) OldSize = 1610612736 (1536.0MB) NewRatio = 7 SurvivorRatio = 8 PermSize = 21757952 (20.75MB) MaxPermSize = 85983232 (82.0MB) New Generation: 45.7% used Eden Space: 46.3% used From Space: 41.4% used To Space: 0.0% used concurrent mark-sweep generation: 63.7% used Perm Generation: 82.5% used
编辑1@H_404_5@
使用pmap我们可以看到有相当多的64Mb分配:@H_404_5@
pmap -x 12663 | grep rwx | sort -n -k3 | less
结果是:@H_404_5@
... a lot more of these 64Mb chunks 00007f32b8000000 0 65508 65508 rwx-- [ anon ] <- what are these? 00007f32ac000000 0 65512 65512 rwx-- [ anon ] 00007f3268000000 0 65516 65516 rwx-- [ anon ] 00007f3324000000 0 65516 65516 rwx-- [ anon ] 00007f32c0000000 0 65520 65520 rwx-- [ anon ] 00007f3314000000 0 65528 65528 rwx-- [ anon ] 00000000401cf000 0 241904 240980 rwx-- [ anon ] <- Direct memory ? 000000077ae00000 0 2139688 2139048 rwx-- [ anon ] <- Heap ?
那么如何找出那些64Mb的块是什么?什么在使用它们?它们中包含哪些数据?@H_404_5@
谢谢@H_404_5@
解决方法
基本上,当你有多个线程分配内存时,glibc会扩大可用竞技场的数量来进行分配,以避免锁争用.竞技场是64Mb大.上限是创建核心竞技场的8倍.当线程访问已经锁定的竞技场时,Arenas将按需创建,以便随着时间的推移而增长.@H_404_5@
在Java中,您可以使用线程,这可以很快导致创建许多竞技场.并且分配遍布这些领域.最初,每个64Mb竞技场只是映射未经注册的内存,但是当您进行分配时,您开始为它们使用实际内存.@H_404_5@
您的pmap可能具有与以下类似的列表.注意324K 65212K = 65536K,560K 64976K == 65536K,620K 64916K == 65536K.也就是说,它们总计达到64Mb.@H_404_5@
00007f4394000000 324K rw--- [ anon ] 00007f4394051000 65212K ----- [ anon ] 00007f4398000000 560K rw--- [ anon ] 00007f439808c000 64976K ----- [ anon ] 00007f439c000000 620K rw--- [ anon ] 00007f439c09b000 64916K ----- [ anon ]
至于变通方法:bug提到了一些你可以设置的环境参数来限制竞技场的数量,但你需要一个足够高的glibc版本.@H_404_5@