Java GC (error de asignación)

129

¿Por qué siempre "GC (Fallo de asignación)"?

Servidor Java HotSpot (TM) de 64 bits VM (25.25-b02) para linux-amd64 JRE ( 1.8.0_25 -b17),

CommandLine flags: 
-XX:CMSInitiatingOccupancyFraction=60 
-XX:GCLogFileSize=10485760 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:InitialHeapSize=32212254720 
-XX:MaxHeapSize=32212254720 
-XX:NewRatio=10 
-XX:OldPLABSize=16 
-XX:ParallelGCThreads=4 
-XX:+PrintGC 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-XX:+PrintStringTableStatistics 
-XX:+PrintTenuringDistribution 
-XX:StringTableSize=1000003 
-XX:SurvivorRatio=4 
-XX:TargetSurvivorRatio=50 
-XX:+UseCompressedClassPointers 
-XX:+UseCompressedOops
-XX:+UseParNewGC 
-XX:+UseConcMarkSweepGC
27.329: [GC (Allocation Failure) 27.329: [ParNew
Desired survivor size 44728320 bytes, new threshold 15 (max 15)
- age   1:   16885304 bytes,   16885304 total
: 349568K->16618K(436928K), 0.2069129 secs] 349568K->16618K(31369920K), 0.2070712 secs] [Times: user=0.78 sys=0.04, real=0.21 secs]


28.210: [GC (Allocation Failure) 28.210: [ParNew
Desired survivor size 44728320 bytes, new threshold 15 (max 15)
- age   1:   28866504 bytes,   28866504 total
- age   2:   12582536 bytes,   41449040 total
: 366186K->47987K(436928K), 0.2144807 secs] 366186K->47987K(31369920K), 0.2146024 secs] [Times: user=0.84 sys=0.01, real=0.22 secs]


29.037: [GC (Allocation Failure) 29.038: [ParNew
Desired survivor size 44728320 bytes, new threshold 2 (max 15)
- age   1:   28443488 bytes,   28443488 total
- age   2:   28386624 bytes,   56830112 total
- age   3:   12579928 bytes,   69410040 total
: 397555K->76018K(436928K), 0.2357352 secs] 397555K->76018K(31369920K), 0.2358535 secs] [Times: user=0.93 sys=0.01, real=0.23 secs]
usuario3644708
fuente

Respuestas:

203

La "falla de asignación" es una de las causas del ciclo de GC.

"Fallo de asignación" significa que no queda más espacio en el Edén para asignar objetos. Por lo tanto, es una causa normal de GC joven.

Las JVM anteriores no imprimían GC debido a ciclos menores de GC.

La "falla de asignación" es casi la única causa posible de GC menor. Otra razón para que el GC menor se active podría ser la fase de comentarios del CMS (si +XX:+ScavengeBeforeRemarkestá habilitada).

Alexey Ragozin
fuente
1
Gracias. Simplemente descubra que la antigua JVM no imprime Falla de asignación.
user3644708
2
No recibo esta respuesta por completo, entonces, ¿se debe evitar o no? "Es la causa normal de la GC joven". ¿Es el joven GC la elección equivocada entonces?
Thomas
77
Sí, este es un comportamiento normal
Alexey Ragozin
183
GC (Fallo de asignación) es una mala elección de palabras para un evento que ocurrirá normalmente muchas veces al día. Esos ingenieros de JVM deberían salir más a menudo y tratar de socializar en el mundo real para que puedan aprender términos más amigables que la gente entienda.
Salvador Valencia
80
@SalvadorValencia Está bien, las personas que leen registros de GC de forma regular tampoco son exactamente "normales". :)
biziclop
8

La "falla de asignación" es la causa de que el GC no sea correcto. Es un resultado de la operación de GC.

El GC se activa cuando no hay espacio para asignar (según la región se realiza un GC menor o mayor). Una vez que se realiza el GC, si se libera espacio lo suficientemente bueno, pero si no hay suficiente tamaño, falla. La falla de asignación es una de esas fallas. El siguiente documento tiene una buena explicación https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html

Kamal Rathod
fuente
1
"(...) se produce una falla de asignación (porque no hay espacio para asignar los objetos vivos de la región que se está evacuando) y se realiza una recolección completa de detener el mundo (STW)". - En Java 1.8, modo servidor, he reproducido una breve pausa y ambas huellas se imprimen juntas: [GC (Fallo de asignación) 2287742K-> 1148645K (2633216K), 0.4571912 segundos] [GC completo (Ergonomía) 1148645K-> 1112141K (3184128K), 2.8563984 segundos]. Así que voté tu respuesta ;-)
Jose Manuel Gomez Alvarez
-10

Cuando use CMS GC en jdk1.8 aparecerá este error, cambio el G1 Gc para resolver este problema.

 -Xss512k -Xms6g -Xmx6g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=70 -XX:NewRatio=1 -XX:SurvivorRatio=6 -XX:G1ReservePercent=10 -XX:G1HeapRegionSize=32m -XX:ConcGCThreads=6 -Xloggc:gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 
Sombrerero Bush
fuente
1
¿Por qué se rechazó esto tantas veces? Una explicación sería útil.
Mike Stoddart
2
¿Porque es como decir que reescribiste tu programa en Rust y ahora no tienes esos mensajes?
simplemente