recolección de basura de Java tiempo "real" es mucho más grande que el "sistema" "usuario" +

Eso es como gc completa con prolijas gc miradas habilitados como -recolección de basura de Java tiempo "real" es mucho más grande que el "sistema" "usuario" +

13463.547: [Full GC [PSYoungGen: 323053K->0K(325952K)] 
      [PSOldGen: 653170K->331738K(655360K)] 976224K->331738K(981312K) 
      [PSPermGen: 238715K->238715K(264448K)], 385.4631490 secs] 
      [Times: user=2.19 sys=1.35, real=385.50 secs]

¿Cómo puede ser mucho más grande que el usuario el tiempo real + sys?

Mi primer pensamiento fue que el recolector de basura está esperando un recurso, pero este recurso no parece ser IO o CPU, ya que la salida "superior" no muestra ninguna CPU o problemas de memoria cuando se produce el gc.

Fuente

2011-08-30 Artiom Gourevitch

Si no está esperando en IO y no está vinculado a la CPU, la única otra cosa en la que puedo pensar es esperar en un semáforo/mutex, o realmente realmente lento acceso a la memoria. – Jonathan

¿usa JNI en su aplicación? ¿Cuál es el tamaño de tu montón y la cantidad de ram física que tienes? – Ron

Xmx = 960 Mb, RAM = 4GB usamos JNI pero no con demasiada frecuencia, ¿cómo afecta JNI a la recolección de basura? –

Para que se produzca la colección completa, debe detener todos los hilos. (Una de las razones por las que llama a detener la colección mundial)

Detener todos tus hilos puede llevar mucho tiempo, especialmente si tienes miles de ellos. Cada hilo debe alcanzar un "punto de seguridad" para detenerlo.

Este tipo de comportamiento generalmente significa que tiene demasiados hilos. También puede considerar el colector ConcurrenntMarkSweep o el nuevo colector G1 que no necesita detener la aplicación con tanta frecuencia.

Fuente

2011-08-30 16:39:30

Esto podría ser una pista. La GC larga ocurre en entornos de control de calidad, donde el agente Yourkit está habilitado. Podría evitar que los hilos lleguen a puntos de seguridad, ya que tuvimos problemas de rendimiento con él antes. –

Intente leer esto (más enlaces incluidos en el documento técnico): Java 1.5 GC Internals.
Supongo que la mayoría de las cosas siguen siendo válidas para la máquina virtual de 1.6 de Java y ofrece una gran idea de cómo funciona el GC.
Además, lea esto: Tuning JVM's 1.6 Heap space
(también hay otro enlace de papel blanco con un punto de referencia ilustrativa, pero simplemente no lo puede encontrar :(:/
voy a tratar de ver si aparece algún lugar, pero supongo que es ubicado en algún lugar del sitio web de Oracle)

En general, no se vuelva raro Pruebe y experimente con diferentes opciones basadas en algunos motivos y vea cómo funciona. A menos que tenga una ganancia de rendimiento> 10% y su aplicación sea crítica, intente no mezclarse con muchos detalles.
La razón es simple: una simple reescritura de código en solo unos pocos LOC puede cambiar drásticamente el comportamiento de su GC.
Tómese su tiempo y diviértase :) :)

Fuente

2011-08-30 17:28:55 Kounavi

recolección de basura de Java tiempo "real" es mucho más grande que el "sistema" "usuario" +

Respuesta

Cuestiones relacionadas