-
Bug
-
Resolution: Incomplete
-
P3
-
None
-
8u72
-
x86_64
-
linux
FULL PRODUCT VERSION :
Java HotSpot(TM) 64-Bit Server VM (25.72-b15) for linux-amd64 JRE (1.8.0_72-b15), built on Dec 22 2015 22:00:07 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8)
Memory: 4k page, physical 8052096k(7191164k free), swap 0k(0k free)
CommandLine flags: -XX:InitialHeapSize=3297771520 -XX:MaxHeapSize=3297771520 -XX:-OmitStackTraceInFastThrow -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:ThreadStackSize=256 -XX:-TraceClassUnloading -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
ADDITIONAL OS VERSION INFORMATION :
CentOS 6 x64
EXTRA RELEVANT SYSTEM CONFIGURATION :
virtual host (hyper-v on windows 2012 R2)
8 GB RAM
swap switched off
2 cpu cores
Jetty 9.2.11 (used NIO)
A DESCRIPTION OF THE PROBLEM :
After we have moved from JRE 1.7.0_76 to JRE 1.8.0_72 in our Web application running in Jetty 9.2.11 we have noticed that the java process consumes significantly more memory (as reported by Linux system) while the heap memory consumption remains the same as before. And the memory consumption rises until it hits certain limit.
With JRE 1.7 we were assigning maximum java stack size (-Xmx) to 40% of available RAM and this does not work any more. Linux boxes that were running with 4 GB RAM before the switch to JRE 1.8, now require 5-6 GB RAM, otherwise a 2 GB swap is full and after some time (from hours to days - based on assigned RAM) the java process is killed by system. The only info on OOM is then present in /var/log/messages:
----
Nov 10 21:29:54 my kernel: Out of memory: Kill process 26610 (java) score 570 or sacrifice child
----
I have monitored the application under different configurations and the interesting thing is that when I enabled swap then the physical memory (RSS) consumed by the java process was declining. This, IMHO, indicates that some of the memory allocated by java process is not used and thus is swapped-off.
We need to find a way how to solve or mitigate this issue.
REGRESSION. Last worked in version 7u76
REPRODUCIBILITY :
This bug can be reproduced always.
Java HotSpot(TM) 64-Bit Server VM (25.72-b15) for linux-amd64 JRE (1.8.0_72-b15), built on Dec 22 2015 22:00:07 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8)
Memory: 4k page, physical 8052096k(7191164k free), swap 0k(0k free)
CommandLine flags: -XX:InitialHeapSize=3297771520 -XX:MaxHeapSize=3297771520 -XX:-OmitStackTraceInFastThrow -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:ThreadStackSize=256 -XX:-TraceClassUnloading -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
ADDITIONAL OS VERSION INFORMATION :
CentOS 6 x64
EXTRA RELEVANT SYSTEM CONFIGURATION :
virtual host (hyper-v on windows 2012 R2)
8 GB RAM
swap switched off
2 cpu cores
Jetty 9.2.11 (used NIO)
A DESCRIPTION OF THE PROBLEM :
After we have moved from JRE 1.7.0_76 to JRE 1.8.0_72 in our Web application running in Jetty 9.2.11 we have noticed that the java process consumes significantly more memory (as reported by Linux system) while the heap memory consumption remains the same as before. And the memory consumption rises until it hits certain limit.
With JRE 1.7 we were assigning maximum java stack size (-Xmx) to 40% of available RAM and this does not work any more. Linux boxes that were running with 4 GB RAM before the switch to JRE 1.8, now require 5-6 GB RAM, otherwise a 2 GB swap is full and after some time (from hours to days - based on assigned RAM) the java process is killed by system. The only info on OOM is then present in /var/log/messages:
----
Nov 10 21:29:54 my kernel: Out of memory: Kill process 26610 (java) score 570 or sacrifice child
----
I have monitored the application under different configurations and the interesting thing is that when I enabled swap then the physical memory (RSS) consumed by the java process was declining. This, IMHO, indicates that some of the memory allocated by java process is not used and thus is swapped-off.
We need to find a way how to solve or mitigate this issue.
REGRESSION. Last worked in version 7u76
REPRODUCIBILITY :
This bug can be reproduced always.