java - tesis - 100% de espacio Eden completo, 0% de espacio de Survivor usado-No se realizó la recolección de basura

tesis de residuos solidos en universidades

Question

Me he encontrado con un caso de GC bastante confuso: si bien el espacio de Eden está lleno al 100%, se usa el espacio de 0% de sobrevivientes. Cuando el Eden está lleno, la recolección de basura debe ser activada, ¿verdad?

¿Puede haber un caso en el que se evite que el demonio GC se ejecute? ¿Te gusta una CPU al 100%?

Estamos utilizando jdk-1.7 .

¿Cuál puede ser la causa? A continuación se muestra la salida de jmap.

También intentamos capturar un uso de memoria más detallado utilizando jmap -histo -F , pero luego el uso de la CPU se redujo a 0% y el proceso de java se volvió inalcanzable.

using thread-local object allocation.
Parallel GC with 18 thread(s)
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 12884901888 (12288.0MB)
NewSize = 1310720 (1.25MB)
MaxNewSize = 17592186044415 MB
OldSize = 5439488 (5.1875MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 21757952 (20.75MB)
MaxPermSize = 85983232 (82.0MB)
G1HeapRegionSize = 0 (0.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 4265738240 (4068.125MB)
used = 4265738240 (4068.125MB)
free = 0 (0.0MB)
100.0% used
From Space:
capacity = 14352384 (13.6875MB)
used = 0 (0.0MB)
free = 14352384 (13.6875MB)
0.0% used
To Space:
capacity = 14680064 (14.0MB)
used = 0 (0.0MB)
free = 14680064 (14.0MB)
0.0% used
PS Old Generation
capacity = 8589934592 (8192.0MB)
used = 8589931920 (8191.997451782227MB)
free = 2672 (0.0025482177734375MB)
99.99996889382601% used
PS Perm Generation
capacity = 41353216 (39.4375MB)
used = 41079056 (39.17604064941406MB)
free = 274160 (0.2614593505859375MB)
99.33702858805468% used

Answer 1

Cálculo de SurvivorRatio:

Si SurvivorRatio = 6, la proporción de (One SurvivorSpace: Eden) = (1: 6).
Así que dos Survivor tomarán (2 partes), y Eden tiene 6 partes. Así que en total 8 partes.
Entonces, si tengo un gen joven de 40 MB, Eden es (6/8 * 40) MB y un sobreviviente tendrá (1/8 * 40) MB.

Si SurvivorRatio = 7. Entonces las partes totales son (7 + 1 + 1 = 9). Eden es (7/9 * 40) MB y el sobreviviente tendrá (1/9 * 40) MB

Teóricamente

 The SurvivorRatio parameter controls the size of the two survivor spaces.
For example, -XX:SurvivorRatio=6 sets the ratio between each survivor space
and eden to be 1:6, each survivor space will be one eighth of the young
generation.

Matemáticamente

S - Sobreviviente
E - Eden
Y - generación joven

if SurvivorRatio=6
then S / E = 1/6
E = 6S
2S + E = Y
2S + 6S = Y
S = Y / 8

Efecto

Si aumentar a más el valor de SurvivorRatio da como resultado un menor espacio para Survivor, los objetos del espacio eden se insertarán directamente en el gen anterior / actual. Menor oportunidad para filtrar objetos en vivo en Survivor Space a través de GC menor. También esto puede aumentar el no de GC completo.

Si reducirlo a un valor más bajo dará como resultado un menor espacio eden hará que el GC menor sea frecuente.

Sepa que el tiempo necesario para un GC menor será más especialmente si estamos usando el algoritmo Serial GC donde solo se usará un solo hilo para GC, aunque su máquina es una máquina de varios núcleos.

También -XX:+UseAdaptiveSizePolicy cuenta que -XX:+UseAdaptiveSizePolicy determinará el propio SurvivorRatio de JVM durante el tiempo de ejecución, pero siempre es mejor mencionarlo manualmente en función de su aplicación al intentar ejecutar una carga múltiple.

Answer 2

Cuando veo en su configuración de Heap encontré que

MaxNewSize = 17592186044415 MB es incorrecto, sin embargo, debe estar en bytes.

Lo que veo es que casi todas las generaciones están llenas y al mismo tiempo y Collector está tratando de reunir ambas generaciones para que se bloqueen entre sí.

Sugiero que por favor ajuste la memoria con los siguientes parámetros.

-XX:NewRatio=3 - the young generation will occupy 1/4 the overall heap
-XX:NewSize - Calculated automatically if you specify -XX:NewRatio
-XX:MaxNewSize - The largest size the young generation can grow to (unlimited if this value is not specified at command line)

También sugiero que use un espacio de sobreviviente que le dará tiempo al recolector cuando los objetos se copien desde la generación de eden a "tenured".

-XX:SurvivorRatio=6 - each survivor space will be 1/8 the young generation

Si los espacios de sobrevivientes son demasiado pequeños, la recopilación de copias se desborda directamente en la generación activa.

Para cualquier aclaración consultar this enlace.

Editar:

-XX:NewRatio=3 - la generación joven ocupará 1/4 del montón general

Cálculo:

 y/t=1/3
y+t=h
y+3y=h
y=h/4
t=tenured
y=young
h=heap

Answer 3

Los buffers locales de hilo se asignan desde el espacio eden. Tan pronto como se asigna un búfer, el espacio libre en el espacio eden se reduce por completo. Esto puede significar que tienes muchos TLAB que están casi vacíos, pero el espacio eden parece estar lleno. Se activa un GC cuando no hay suficiente espacio libre en el espacio eden.

Si desactiva TLAB -XX:-UseTLAB esto ralentizará el rendimiento, pero obtendrá un -XX:-UseTLAB muy preciso de cómo se utiliza el espacio.

Answer 4

Solo un pensamiento pero veo que la Vieja Gen también está llena. Podría ser que el GC en lugar de intentar limpiar Eden está ocupado ejecutando un GC completo tratando de limpiar la Vieja Generación para evitar la OOM.