From binoydalal93 at gmail.com Thu May 10 14:39:20 2018 From: binoydalal93 at gmail.com (Binoy Dalal) Date: Thu, 10 May 2018 14:39:20 +0000 Subject: Consecutive Full GCs but no OOM Message-ID: Hi, I'm troubleshooting a Java web application which runs fine for a while after which the heap suddenly spikes up to 100% and this results in consecutive Full GCs with almost no old gen being cleared out. This however does not result in an OOM with the usual java.lang.OutOfMemoryError: GC overhead limit exceeded message. How could this be? Here are 6 Full GC entries: gc_20180423_1443.log.11.current:37491:2018-05-01T09:10:52.156+0000: 671212.664: [Full GC (Allocation Failure) 2018-05-01T09:10:52.156+0000: 671212.664: [CMS: 7077887K->7077887K(7077888K), 28.6425809 secs] 9043967K->9043787K(9043968K), [Metaspace: 75140K->75140K(1118208K)], 28.6428227 secs] [Times: user=28.63 sys=0.00, real=28.64 secs] gc_20180423_1443.log.11.current:37510:2018-05-01T09:11:20.803+0000: 671241.311: [Full GC (Allocation Failure) 2018-05-01T09:11:20.803+0000: 671241.311: [CMS: 7077887K->7077888K(7077888K), 42.8881300 secs] 9043964K->9043856K(9043968K), [Metaspace: 75140K->75140K(1118208K)], 42.8883826 secs] [Times: user=42.85 sys=0.01, real=42.89 secs] gc_20180423_1443.log.11.current:37529:2018-05-01T09:12:03.694+0000: 671284.201: [Full GC (Allocation Failure) 2018-05-01T09:12:03.694+0000: 671284.201: [CMS: 7077888K->7077888K(7077888K), 28.8305893 secs] 9043959K->9043845K(9043968K), [Metaspace: 75140K->75140K(1118208K)], 28.8308264 secs] [Times: user=28.83 sys=0.01, real=28.83 secs] gc_20180423_1443.log.11.current:37548:2018-05-01T09:12:32.527+0000: 671313.035: [Full GC (Allocation Failure) 2018-05-01T09:12:32.527+0000: 671313.035: [CMS: 7077888K->7077887K(7077888K), 34.2235811 secs] 9043967K->9043802K(9043968K), [Metaspace: 75140K->75140K(1118208K)], 34.2238304 secs] [Times: user=34.22 sys=0.00, real=34.23 secs] gc_20180423_1443.log.11.current:37567:2018-05-01T09:13:06.754+0000: 671347.261: [Full GC (Allocation Failure) 2018-05-01T09:13:06.754+0000: 671347.262: [CMS: 7077887K->7077887K(7077888K), 30.2722671 secs] 9043966K->9043854K(9043968K), [Metaspace: 75140K->75140K(1118208K)], 30.2725042 secs] [Times: user=30.27 sys=0.00, real=30.27 secs] gc_20180423_1443.log.11.current:37586:2018-05-01T09:13:37.028+0000: 671377.536: [Full GC (Allocation Failure) 2018-05-01T09:13:37.028+0000: 671377.536: [CMS: 7077887K->7077887K(7077888K), 35.6276778 secs] 9043955K->9043843K(9043968K), [Metaspace: 75140K->75140K(1118208K)], 35.6278998 secs] [Times: user=35.61 sys=0.01, real=35.63 secs] As per my calculations total duration based on the logs for these 6 entries is 164.872s out of which GC takes up 164.8583663s which equals 99.99% time in GC. Given total heap of 9043968K bring 2% to 180879.36K. The total heap cleared from the logs in these 5 executions is 679K (across the calls) which is way less than 2% yet there's no OOM thrown. The -XX:-UseGCOverheadLimit flag has not been used. Here's a list of the GC params: CommandLine flags: -XX:CICompilerCount=4 -XX:CMSInitiatingOccupancyFraction=50 -XX:CMSMaxAbortablePrecleanTime=6000 -XX:+CMSParallelRemarkEnabled -XX:+CMSScavengeBeforeRemark -XX:ConcGCThreads=4 -XX:+CrashOnOutOfMemoryError -XX:GCLogFileSize=10485760 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/WORK/log/solr/solr.hprof -XX:InitialHeapSize=9663676416 -XX:LogFile=/WORK/log/solr/vm.log -XX:+LogVMOutput -XX:MaxHeapSize=9663676416 -XX:MaxNewSize=2415919104 -XX:MaxTenuringThreshold=8 -XX:MinHeapDeltaBytes=196608 -XX:NewRatio=3 -XX:NewSize=2415919104 -XX:NumberOfGCLogFiles=20 -XX:OldPLABSize=16 -XX:OldSize=7247757312 -XX:OnOutOfMemoryError=/WORK/bin/oom.sh solr -XX:ParallelGCThreads=4 -XX:+ParallelRefProcEnabled -XX:PretenureSizeThreshold=67108864 -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+PrintTenuringDistribution -XX:+SafepointTimeout -XX:SafepointTimeoutDelay=500 -XX:SurvivorRatio=4 -XX:TargetSurvivorRatio=90 -XX:ThreadStackSize=256 -XX:+UnlockDiagnosticVMOptions -XX:-UseBiasedLocking -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseGCLogFileRotation -XX:+UseParNewGC JDK version is openjdk-1.8.0_151 Please let me know if you spot an error in my calculations or my understanding of thejava.lang.OutOfMemoryError: GC overhead limit exceeded rule that error is thrown when more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered. Any pointers are much appreciated. Thanks! I have posted this same question on stack overflow in case anyone wants to respond there: https://stackoverflow.com/questions/50181547/95-consecutive-full-gcs-but-no-oom-how-could-that-happen -- Regards, Binoy Dalal -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Mon May 14 17:41:42 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 14 May 2018 19:41:42 +0200 Subject: Consecutive Full GCs but no OOM In-Reply-To: References: Message-ID: <29e8c4d7e676e63540c29f778d0119b6b5975076.camel@oracle.com> Hi, On Thu, 2018-05-10 at 14:39 +0000, Binoy Dalal wrote: > Hi, > I'm troubleshooting a Java web application which runs fine for a > while after which the heap suddenly spikes up to 100% and this > results in consecutive Full GCs with almost no old gen being cleared > out. This however does not result in an OOM with the > usual java.lang.OutOfMemoryError: GC overhead limit exceeded message. > How could this be? > Here are 6 Full GC entries: > > gc_20180423_1443.log.11.current:37491:2018-05-01T09:10:52.156+0000: > 671212.664: [Full GC (Allocation Failure) 2018-05- > 01T09:10:52.156+0000: 671212.664: [CMS: 7077887K->7077887K(7077888K), > 28.6425809 secs] 9043967K->9043787K(9043968K), [Metaspace: 75140K- > >75140K(1118208K)], 28.6428227 secs] [Times: user=28.63 sys=0.00, > real=28.64 secs] > gc_20180423_1443.log.11.current:37510:2018-05-01T09:11:20.803+0000: > 671241.311: [Full GC (Allocation Failure) 2018-05- > 01T09:11:20.803+0000: 671241.311: [CMS: 7077887K->7077888K(7077888K), > 42.8881300 secs] 9043964K->9043856K(9043968K), [Metaspace: 75140K- > >75140K(1118208K)], 42.8883826 secs] [Times: user=42.85 sys=0.01, > real=42.89 secs] > gc_20180423_1443.log.11.current:37529:2018-05-01T09:12:03.694+0000: > 671284.201: [Full GC (Allocation Failure) 2018-05- > 01T09:12:03.694+0000: 671284.201: [CMS: 7077888K->7077888K(7077888K), > 28.8305893 secs] 9043959K->9043845K(9043968K), [Metaspace: 75140K- > >75140K(1118208K)], 28.8308264 secs] [Times: user=28.83 sys=0.01, > real=28.83 secs] > gc_20180423_1443.log.11.current:37548:2018-05-01T09:12:32.527+0000: > 671313.035: [Full GC (Allocation Failure) 2018-05- > 01T09:12:32.527+0000: 671313.035: [CMS: 7077888K->7077887K(7077888K), > 34.2235811 secs] 9043967K->9043802K(9043968K), [Metaspace: 75140K- > >75140K(1118208K)], 34.2238304 secs] [Times: user=34.22 sys=0.00, > real=34.23 secs] > gc_20180423_1443.log.11.current:37567:2018-05-01T09:13:06.754+0000: > 671347.261: [Full GC (Allocation Failure) 2018-05- > 01T09:13:06.754+0000: 671347.262: [CMS: 7077887K->7077887K(7077888K), > 30.2722671 secs] 9043966K->9043854K(9043968K), [Metaspace: 75140K- > >75140K(1118208K)], 30.2725042 secs] [Times: user=30.27 sys=0.00, > real=30.27 secs] > gc_20180423_1443.log.11.current:37586:2018-05-01T09:13:37.028+0000: > 671377.536: [Full GC (Allocation Failure) 2018-05- > 01T09:13:37.028+0000: 671377.536: [CMS: 7077887K->7077887K(7077888K), > 35.6276778 secs] 9043955K->9043843K(9043968K), [Metaspace: 75140K- > >75140K(1118208K)], 35.6278998 secs] [Times: user=35.61 sys=0.01, > real=35.63 secs] > As per my calculations total duration based on the logs for these 6 > entries is 164.872s out of which GC takes up 164.8583663s which > equals 99.99% time in GC. Given total heap of 9043968K bring 2% to > 180879.36K. > > The total heap cleared from the logs in these 5 executions is 679K > (across the calls) which is way less than 2% yet there's no OOM > thrown. > > The -XX:-UseGCOverheadLimit flag has not been used. > > Here's a list of the GC params: There is unfortunately no way to get detailed information in a product build about what Hotspot thinks. However not only gc overhead is accounted for in the decision to give an OOME, but also how much memory the full gcs free. Probably the most important flag here would be GCHeapFreeLimit: simplified, if free space after full gc is below this percentage of total heap, that full gc does not count against GCOverHeadLimit. Looking at the log output, after Full GC there is ~4% of max heap available. The default value for GCOverHeadLimit is 2 (percent). This might be the reason why there is no OOME. Thanks, Thomas From java at elyograg.org Mon May 14 19:22:33 2018 From: java at elyograg.org (Shawn Heisey) Date: Mon, 14 May 2018 13:22:33 -0600 Subject: Consecutive Full GCs but no OOM In-Reply-To: <29e8c4d7e676e63540c29f778d0119b6b5975076.camel@oracle.com> References: <29e8c4d7e676e63540c29f778d0119b6b5975076.camel@oracle.com> Message-ID: On 5/14/2018 11:41 AM, Thomas Schatzl wrote: > However not only gc overhead is accounted for in the decision to give > an OOME, but also how much memory the full gcs free. > > Probably the most important flag here would be GCHeapFreeLimit: > simplified, if free space after full gc is below this percentage of > total heap, that full gc does not count against GCOverHeadLimit. > > Looking at the log output, after Full GC there is ~4% of max heap > available. The default value for GCOverHeadLimit is 2 (percent). I have a question sparked by this discussion, but it's only indirectly related. How long a timeframe is examined to determine whether the 98% and 2% thresholds are violated? This information is not in the documentation that I've been able to find. Here's an example of a java 8 documentation link where that information is not shown: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html#sthref35 Thanks, Shawn From thomas.schatzl at oracle.com Mon May 14 19:45:55 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 14 May 2018 21:45:55 +0200 Subject: Consecutive Full GCs but no OOM In-Reply-To: References: <29e8c4d7e676e63540c29f778d0119b6b5975076.camel@oracle.com> Message-ID: Hi, On Mon, 2018-05-14 at 13:22 -0600, Shawn Heisey wrote: > On 5/14/2018 11:41 AM, Thomas Schatzl wrote: > > There is unfortunately no way to get detailed information in a > > product build about what Hotspot thinks. To clarify that statement a bit: you need to enable -XX:+Verbose to get exact information on what Hotspot thinks, but Verbose can only be changed in debug builds. In JDK9+ you could use -Xlog:gc+ergo=trace to get this information.. > > However not only gc overhead is accounted for in the decision to > > give an OOME, but also how much memory the full gcs free. > > > > Probably the most important flag here would be GCHeapFreeLimit: > > simplified, if free space after full gc is below this percentage of > > total heap, that full gc does not count against GCOverHeadLimit. > > > > Looking at the log output, after Full GC there is ~4% of max heap > > available. The default value for GCOverHeadLimit is 2 (percent). > > I have a question sparked by this discussion, but it's only > indirectly related. > > How long a timeframe is examined to determine whether the 98% and 2% > thresholds are violated? This information is not in the > documentation that I've been able to find. Here's an example of a > java 8 documentation link where that information is not shown: > > https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cm > s.html#sthref35 I did not think this is actually documented - I had to look at the code :) There is a flag called AdaptiveSizePolicyGCTimeLimitThreshold (default: 5) which defines the amount of consecutive GCs that need to exceed these thresholds to result in an OOME. That counter is reset at the first GC not exceeding the thresholds. I hope this was what you were asking for. Thanks, Thomas From java at elyograg.org Mon May 14 21:29:18 2018 From: java at elyograg.org (Shawn Heisey) Date: Mon, 14 May 2018 15:29:18 -0600 Subject: Consecutive Full GCs but no OOM In-Reply-To: References: <29e8c4d7e676e63540c29f778d0119b6b5975076.camel@oracle.com> Message-ID: On 5/14/2018 1:45 PM, Thomas Schatzl wrote: > I did not think this is actually documented - I had to look at the > code :) > > There is a flag called AdaptiveSizePolicyGCTimeLimitThreshold (default: > 5) which defines the amount of consecutive GCs that need to exceed > these thresholds to result in an OOME. That counter is reset at the > first GC not exceeding the thresholds. > > I hope this was what you were asking for. Yep, that's exactly what I was looking for. Expected a timeframe (perhaps one or five minutes) rather than a collection count, but as long as the check is well-written, I don't think that's a problem. I have done very little diving into Java's source code, so I can't comment about how good it is. Thanks, Shawn From thomas.schatzl at oracle.com Tue May 15 07:29:34 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 15 May 2018 09:29:34 +0200 Subject: Consecutive Full GCs but no OOM In-Reply-To: References: <29e8c4d7e676e63540c29f778d0119b6b5975076.camel@oracle.com> Message-ID: <13048870611906480d57d3c6504a5dfbbfcc9336.camel@oracle.com> Hi, On Mon, 2018-05-14 at 15:29 -0600, Shawn Heisey wrote: > On 5/14/2018 1:45 PM, Thomas Schatzl wrote: > > I did not think this is actually documented - I had to look at > > the > > code :) > > > > There is a flag called AdaptiveSizePolicyGCTimeLimitThreshold > > (default: > > 5) which defines the amount of consecutive GCs that need to exceed > > these thresholds to result in an OOME. That counter is reset at the > > first GC not exceeding the thresholds. > > > > I hope this was what you were asking for. > > Yep, that's exactly what I was looking for. Expected a timeframe > (perhaps one or five minutes) rather than a collection count, but as > long as the check is well-written, I don't think that's a problem. I > have done very little diving into Java's source code, so I can't > comment about how good it is. > if you want to see the gory details, look at AdaptiveSizePolicy::check_gc_overhead_limit() (line 471+) in http://hg. openjdk.java.net/jdk8u/jdk8u60/hotspot/file/37240c1019fd/src/share/vm/g c_implementation/shared/adaptiveSizePolicy.cpp Thanks, Thomas From thomas.schatzl at oracle.com Fri May 25 17:19:48 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 25 May 2018 19:19:48 +0200 Subject: Consecutive Full GCs but no OOM In-Reply-To: References: <29e8c4d7e676e63540c29f778d0119b6b5975076.camel@oracle.com> Message-ID: <5f34222e6110517094551de1ebaf52d922516e48.camel@oracle.com> Hi Binoi, On Fri, 2018-05-25 at 22:35 +0530, Binoy Dalal wrote: > Thomas, > Thanks for your response. > How did you calculate 4% remaining? > Is there some error in my calculations because the total amount of > heap cleared is 679K which is less than 2%(180879.36K) of the total > heap (9043968K)? Or am I using incorrect parameters while > calculating? "Probably the most important flag here would be GCHeapFreeLimit: simplified, if free space after full gc is below this percentage of total heap, that full gc does not count against GCOverHeadLimit." Total heap is the size given by -XX:MaxHeapSize. I.e. -XX:MaxHeapSize=9663676416 = 9216MB The total heap after full gc is e.g. 9043968K, i.e. 8832 MB. 1 - 8832/9216 = 4.17%. Thanks, Thomas From ecki at zusammenkunft.net Fri May 25 19:53:56 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 25 May 2018 19:53:56 +0000 Subject: Consecutive Full GCs but no OOM In-Reply-To: <5f34222e6110517094551de1ebaf52d922516e48.camel@oracle.com> References: <29e8c4d7e676e63540c29f778d0119b6b5975076.camel@oracle.com> , <5f34222e6110517094551de1ebaf52d922516e48.camel@oracle.com> Message-ID: Hello Thomas, Is it possible that the default is too small or it should not apply to full heap but oldgen instead? If one survivor and potential eden is empty (or equivalent region in G1) it still should consider consecutive full GCs (triggered by full oldgen), or did I missunderstand? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: hotspot-gc-use on behalf of Thomas Schatzl Sent: Friday, May 25, 2018 7:19:48 PM To: Binoy Dalal Cc: hotspot-gc-use at openjdk.java.net Subject: Re: Consecutive Full GCs but no OOM Hi Binoi, On Fri, 2018-05-25 at 22:35 +0530, Binoy Dalal wrote: > Thomas, > Thanks for your response. > How did you calculate 4% remaining? > Is there some error in my calculations because the total amount of > heap cleared is 679K which is less than 2%(180879.36K) of the total > heap (9043968K)? Or am I using incorrect parameters while > calculating? "Probably the most important flag here would be GCHeapFreeLimit: simplified, if free space after full gc is below this percentage of total heap, that full gc does not count against GCOverHeadLimit." Total heap is the size given by -XX:MaxHeapSize. I.e. -XX:MaxHeapSize=9663676416 = 9216MB The total heap after full gc is e.g. 9043968K, i.e. 8832 MB. 1 - 8832/9216 = 4.17%. Thanks, Thomas _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From binoydalal93 at gmail.com Fri May 25 17:05:15 2018 From: binoydalal93 at gmail.com (Binoy Dalal) Date: Fri, 25 May 2018 22:35:15 +0530 Subject: Consecutive Full GCs but no OOM In-Reply-To: <29e8c4d7e676e63540c29f778d0119b6b5975076.camel@oracle.com> References: <29e8c4d7e676e63540c29f778d0119b6b5975076.camel@oracle.com> Message-ID: Thomas, Thanks for your response. How did you calculate 4% remaining? Is there some error in my calculations because the total amount of heap cleared is 679K which is less than 2%(180879.36K) of the total heap (9043968K)? Or am I using incorrect parameters while calculating? Thanks. On Mon, May 14, 2018 at 11:11 PM Thomas Schatzl wrote: > Hi, > > On Thu, 2018-05-10 at 14:39 +0000, Binoy Dalal wrote: > > Hi, > > I'm troubleshooting a Java web application which runs fine for a > > while after which the heap suddenly spikes up to 100% and this > > results in consecutive Full GCs with almost no old gen being cleared > > out. This however does not result in an OOM with the > > usual java.lang.OutOfMemoryError: GC overhead limit exceeded message. > > How could this be? > > Here are 6 Full GC entries: > > > > gc_20180423_1443.log.11.current:37491:2018-05-01T09:10:52.156+0000: > > 671212.664: [Full GC (Allocation Failure) 2018-05- > > 01T09:10:52.156+0000: 671212.664: [CMS: 7077887K->7077887K(7077888K), > > 28.6425809 secs] 9043967K->9043787K(9043968K), [Metaspace: 75140K- > > >75140K(1118208K)], 28.6428227 secs] [Times: user=28.63 sys=0.00, > > real=28.64 secs] > > gc_20180423_1443.log.11.current:37510:2018-05-01T09:11:20.803+0000: > > 671241.311: [Full GC (Allocation Failure) 2018-05- > > 01T09:11:20.803+0000: 671241.311: [CMS: 7077887K->7077888K(7077888K), > > 42.8881300 secs] 9043964K->9043856K(9043968K), [Metaspace: 75140K- > > >75140K(1118208K)], 42.8883826 secs] [Times: user=42.85 sys=0.01, > > real=42.89 secs] > > gc_20180423_1443.log.11.current:37529:2018-05-01T09:12:03.694+0000: > > 671284.201: [Full GC (Allocation Failure) 2018-05- > > 01T09:12:03.694+0000: 671284.201: [CMS: 7077888K->7077888K(7077888K), > > 28.8305893 secs] 9043959K->9043845K(9043968K), [Metaspace: 75140K- > > >75140K(1118208K)], 28.8308264 secs] [Times: user=28.83 sys=0.01, > > real=28.83 secs] > > gc_20180423_1443.log.11.current:37548:2018-05-01T09:12:32.527+0000: > > 671313.035: [Full GC (Allocation Failure) 2018-05- > > 01T09:12:32.527+0000: 671313.035: [CMS: 7077888K->7077887K(7077888K), > > 34.2235811 secs] 9043967K->9043802K(9043968K), [Metaspace: 75140K- > > >75140K(1118208K)], 34.2238304 secs] [Times: user=34.22 sys=0.00, > > real=34.23 secs] > > gc_20180423_1443.log.11.current:37567:2018-05-01T09:13:06.754+0000: > > 671347.261: [Full GC (Allocation Failure) 2018-05- > > 01T09:13:06.754+0000: 671347.262: [CMS: 7077887K->7077887K(7077888K), > > 30.2722671 secs] 9043966K->9043854K(9043968K), [Metaspace: 75140K- > > >75140K(1118208K)], 30.2725042 secs] [Times: user=30.27 sys=0.00, > > real=30.27 secs] > > gc_20180423_1443.log.11.current:37586:2018-05-01T09:13:37.028+0000: > > 671377.536: [Full GC (Allocation Failure) 2018-05- > > 01T09:13:37.028+0000: 671377.536: [CMS: 7077887K->7077887K(7077888K), > > 35.6276778 secs] 9043955K->9043843K(9043968K), [Metaspace: 75140K- > > >75140K(1118208K)], 35.6278998 secs] [Times: user=35.61 sys=0.01, > > real=35.63 secs] > > As per my calculations total duration based on the logs for these 6 > > entries is 164.872s out of which GC takes up 164.8583663s which > > equals 99.99% time in GC. Given total heap of 9043968K bring 2% to > > 180879.36K. > > > > The total heap cleared from the logs in these 5 executions is 679K > > (across the calls) which is way less than 2% yet there's no OOM > > thrown. > > > > The -XX:-UseGCOverheadLimit flag has not been used. > > > > Here's a list of the GC params: > > There is unfortunately no way to get detailed information in a product > build about what Hotspot thinks. > > However not only gc overhead is accounted for in the decision to give > an OOME, but also how much memory the full gcs free. > > Probably the most important flag here would be GCHeapFreeLimit: > simplified, if free space after full gc is below this percentage of > total heap, that full gc does not count against GCOverHeadLimit. > > Looking at the log output, after Full GC there is ~4% of max heap > available. The default value for GCOverHeadLimit is 2 (percent). > > This might be the reason why there is no OOME. > > Thanks, > Thomas > -- Regards, Binoy Dalal -------------- next part -------------- An HTML attachment was scrubbed... URL: