Long young generation GC?
higuava at gmail.com
Tue Oct 26 07:07:04 PDT 2010
Here is additional information about the machine running the JVM. It
is a virtual machine running in a private cloud. Could it be something
like swapping that caused problem?
On Mon, Oct 25, 2010 at 8:51 PM, Y. Srinivas Ramakrishna
<y.s.ramakrishna at oracle.com> wrote:
> On 10/25/2010 5:49 PM, Y. Srinivas Ramakrishna wrote:
>> On 10/25/2010 5:32 PM, Hi Guava wrote:
>>> The third young generation GC took 439.2720750 secs but the user and
>>> real time are only 0.08 seconds. What does it mean?
>> The machine may be using NTP, and the time may have been changed?
> Seems a rather large jump, so may not be NTP (which i am told uses
> adjtime() to slowly accelerate the time forward or decelerate it backward),
> but rather an abrupt perhaps manual change in TOD.
> Over to the experts....
>> JVM timestamps on Linux seem still to be based on TOD rather than
>> on TSC. Someone in the runtime team (cc'd) may have more detail on
>> why that might still be so.
>> -- ramki
>>> 72667.213: [GC 72667.213: [ParNew: 38336K->4224K(38336K), 1.2473840 secs]
>>> 3443948K->3420569K(6549376K), 1.2474290 secs] [Times: user=0.64 sys=1.10,
>>> real=1.25 secs]
>>> 72680.531: [GC 72680.532: [ParNew: 38336K->4221K(38336K), 0.2916570 secs]
>>> 3008948K->2979033K(6549376K), 0.2916710 secs] [Times: user=0.26 sys=0.03,
>>> real=0.29 secs]
>>> 72681.425: [GC 72681.426: [ParNew: 38325K->4224K(38336K), 439.2720750
>>> secs] 3013053K->2979055K(6549376K), 439.2720750 secs] [Times: user=0.08
>>> sys=0.00, real=0.08 secs]
>>> Java HotSpot(TM) 64-Bit Server VM Version 1.6.0_20-b02
>>> Linux Version 2.6.18-128.1.1.el5 on amd64
>>> hotspot-gc-use mailing list
>>> hotspot-gc-use at openjdk.java.net
More information about the hotspot-runtime-dev