java - Can PermGen leak out into native heap? -
we running glassfish application below settings:
-xx:permsize=1g -xx:maxpermsize=2g -xms4g -xmx4g -xx:maxdirectmemorysize=1048576 jdk version 6u45
we're observing memory leak - java process of glassfish grows - res getting > 15gb (our server has 16gb of physical memory, admins restart glassfish before hitting physical limits), never java.lang.outofmemoryerror.
the output of jmap -permstat after letting application run long time, showing classloaders occupying ~9.5gb (!!!):
class_loader classes bytes parent_loader alive? type <bootstrap> 4242 24064120 null live <internal> 0x0000000794a4c030 20 274072 0x0000000794a4c098 dead groovy/lang/groovyclassloader$innerloader@0x0000000609cdc9f0 ... <many, many groovy class loaders> 0x000000077f9c80d8 0 0 0x00000007017859f8 dead groovy/lang/groovyclassloader@0x0000000609997f00 0x000000076d63b3e0 0 0 0x00000007017859f8 dead groovy/lang/groovyclassloader@0x0000000609997f00 0x000000075a4c5248 20 261784 0x000000075a4c52b0 dead groovy/lang/groovyclassloader$innerloader@0x0000000609cdc9f0 0x000000078ea2e998 0 0 0x00000007017859f8 dead groovy/lang/groovyclassloader@0x0000000609997f00 ... total = 73518 745295 9690318280 n/a alive=1, dead=73517 n/a at same time jmap -heap shows permgen using 700mb:
ps perm generation capacity = 2147483648 (2048.0mb) used = 823831536 (785.6669769287109mb) free = 1323652112 (1262.333023071289mb) 38.362645357847214% used i thought using -xx:maxpermsize , -xmx can control how memory java process allocate (throwing oom in case needed more). understanding process should take to:
4g (heap) + 2g (permgen) + n*1mb (n thread's stacks) ~= 7.5g (by 500 threads) the question
we know leak comes old groovy version , missing permgen sweeping flags, how possible classloaders occupy 9.5gb of memory not belong neither permgen nor java heap?
edit
just clarification - question not how solve memory leak issue, it's how come jvm allows such memory allocation.
not of answer, however. tricky. aware jvm's going use wiggle room garbage collection (especially g1), metaspace : permgen in java8 ( not applicable in case), jit optimization, , direct buffers may reside outside of normal garbage-collected heap.
in either case, analyze heap dump see application behavior. bug in application in jvm. should let application run in outofmemory , see exact cause mentioned.
Comments
Post a Comment