Thanks Thomas!
>>>Short-lived humongous objects that are not arrays of j.l.O. are not
>>>that bad - G1 gets rid of them quickly. G1 tries to reclaim them every
>>>GC.
Yes, I totally agree. Due to time limitation, we didn't go through
automation test suite full run, so we are concerned about humong
Hi Team,
Thanks for suggestions.
We changed our JVM parameters as below. Kindly let us know whether these
parameters are fine our application which serves almost 5 web service
requests on each managed server( 6 managed servers).
-Xms6144m -Xmx6144m -Doracle.ons.maxconnections=3
-Djava.net.
Hi Narashimha,
On Sat, 2018-08-04 at 07:58 +, Narasimha C Achi wrote:
> Hi Team,
>
> Please find attached logs. java web services are deployed in these
> servers.
> Attachment 1: shows to-space exhausted and allocation failure
> Attachment2: Log GC Pauses.
>
> Please find below G1 GC setti
Hi Roy,
On Wed, 2018-08-08 at 15:14 +0800, Roy Zhang wrote:
> Hi All,
>
> Currently we are evaluating G1 in our company, find uncertainty of
> humongous object is major show stopper issue to roll out G1 in our
> production.
> Our heap size is 36G, region size is 16M determined ergonomically by
>
Hi All,
Currently we are evaluating G1 in our company, find uncertainty of
humongous object is major show stopper issue to roll out G1 in our
production.
Our heap size is 36G, region size is 16M determined ergonomically by JVM,
we find there are about 800~1300 humongous regions during some period
Hi,
maybe pmap can help shed some light on this.
Memory mapped files/stuff (like GPU registers/mem) also contribute to
virtual size without actually using RAM, could that be the cause?
Wolfgang
Am 08.08.2018 um 04:40 schrieb Tao Mao:
Hi gc exports,
I have a Java application with following
