Messages du journal Java Garbage Collection

J’ai configuré Java pour vider les informations de récupération de place dans les journaux ( GC détaillé ). Je ne suis pas sûr de ce que signifient les entrées de récupération de place dans les journaux. Un exemple de ces entrées est affiché ci-dessous. J’ai cherché sur Google et je n’ai pas trouvé d’explications solides.

J’ai des suppositions raisonnables, mais je cherche des réponses qui fournissent des définitions ssortingctes de ce que signifient les nombres dans les entrées, soutenus par des sources crédibles. Un +1 automatique à toutes les réponses qui citent la documentation du soleil. Mes questions sont:

  1. Que fait PSYoungGen? Je suppose que cela a quelque chose à voir avec la génération précédente (plus jeune?), Mais quoi exactement?
  2. Quelle est la différence entre le deuxième sortingplet de nombres et le premier?
  3. Pourquoi un nom (PSYoungGen) est-il spécifié pour le premier sortingplet de nombres mais pas pour le second?
  4. Que signifie chaque nombre (taille de la mémoire) dans le sortingplet? Par exemple, dans 109884K-> 14201K (139904K), est la mémoire avant GC 109884k et puis il est réduit à 14201K. Comment le troisième numéro est-il pertinent? Pourquoi exigerions-nous une deuxième série de chiffres?

8109.128: [GC [PSYoungGen: 109884K-> 14201K (139904K)] 691015K-> 595332K (1119040K), 0.0454530 secs]

8112.111: [GC [PSYoungGen: 126649K-> 15528K (142336K)] 707780K-> 605892K (1121472K), 0,0934560 secs]

8112.802: [GC [PSYoungGen: 130344K-> 3732K (118592K)] 720708K-> 607895K (1097728K), 0,0682690 secondes]

    La majeure partie est expliquée dans le Guide de réglage du GC (que vous feriez bien de lire de toute façon).

    L’option de ligne de commande -verbose:gc entraîne l’ -verbose:gc informations sur le -verbose:gc et la récupération de place sur chaque collection. Par exemple, voici une sortie d’une grande application serveur:

     [GC 325407K->83000K(776768K), 0.2300771 secs] [GC 325816K->83372K(776768K), 0.2454258 secs] [Full GC 267628K->83769K(776768K), 1.8479984 secs] 

    Nous voyons ici deux collections mineures suivies d’une collection majeure. Les nombres avant et après la flèche (par exemple, 325407K->83000K de la première ligne) indiquent la taille combinée des objects 325407K->83000K avant et après la récupération de place, respectivement. Après les collections mineures, la taille inclut certains objects qui ne sont plus en état de fonctionner, mais qui ne peuvent pas être récupérés. Ces objects sont soit contenus dans la génération permanente, soit référencés par les générations permanentes ou permanentes.

    Le nombre suivant entre parenthèses (par exemple, à nouveau (776768K) à partir de la première ligne) correspond à la taille (776768K) du tas: la quantité d’espace utilisable pour les objects Java sans demander plus de mémoire au système d’exploitation. Notez que ce nombre n’inclut pas l’un des espaces de survie, car un seul peut être utilisé à un moment donné et n’inclut pas non plus la génération permanente, qui contient les métadonnées utilisées par la machine virtuelle.

    Le dernier élément de la ligne (par exemple, 0.2300771 secs ) indique le temps nécessaire pour effectuer la collecte; dans ce cas environ un quart de seconde.

    Le format de la collection principale de la troisième ligne est similaire.

    Le format de la sortie produite par -verbose:gc est susceptible de changer dans les versions futures.

    Je ne sais pas pourquoi il y a un PSYoungGen dans le vôtre; avez-vous changé le ramasse-miettes?

    1. PSYoungGen fait référence au récupérateur de mémoire utilisé pour la collection secondaire. PS signifie Parallel Scavenge.
    2. Le premier ensemble de nombres correspond aux tailles avant / après de la jeune génération et le second ensemble concerne le segment entier. ( Le diagnostic d’un problème de récupération de place détaille le format)
    3. Le nom indique la génération et le collecteur en question, le second ensemble concerne l’intégralité du tas.

    Un exemple de GC complet associé montre également les collecteurs utilisés pour les générations anciennes et permanentes:

     3.757: [Full GC [PSYoungGen: 2672K->0K(35584K)] [ParOldGen: 3225K->5735K(43712K)] 5898K->5735K(79296K) [PSPermGen: 13533K->13516K(27584K)], 0.0860402 secs] 

    Enfin, en décomposant une ligne de votre exemple de sortie de journal:

     8109.128: [GC [PSYoungGen: 109884K->14201K(139904K)] 691015K->595332K(1119040K), 0.0454530 secs] 
    • 107Mo utilisé avant GC, 14Mb utilisé après GC, taille maximale jeune génération 137Mb
    • Tas de 675 Mo utilisés avant GC, segment de mémoire de 581 Mo utilisé après GC, taille de segment de mémoire maximale de 1 Go
    • GC mineur a eu lieu 8109.128 secondes depuis le début de la JVM et a pris 0.04 secondes

    Je voulais juste mentionner que l’on peut obtenir le journal détaillé du GC avec le

     -XX:+PrintGCDetails 

    paramètre. Ensuite, vous voyez la sortie PSYoungGen ou PSPermGen comme dans la réponse.

    Aussi -Xloggc:gc.log semble générer la même sortie que -verbose:gc mais vous pouvez spécifier un fichier de sortie dans le premier.

    Exemple d’utilisation:

     java -Xloggc:./memory.log -XX:+PrintGCDetails Memory 

    Pour mieux visualiser les données, vous pouvez essayer gcviewer (une version plus récente se trouve sur github ).

    Prenez soin d’écrire les parameters correctement, j’ai oublié le “+” et mon JBoss ne démarre pas, sans aucun message d’erreur!