L'entrée de journal java garbage collection "Full GC (System)" signifie-t-elle une classe appelée System.gc ()?
Que signifie l'entrée" Full GC (System) " dans les journaux de récupération de place? Cette classe appelée Système.gc ()?
Mes journaux de récupération de place ont deux types d'entrée différents pour 'full gc'? L'un avec le mot "Système", l'autre sans. Quelle est la différence?
(Mise à jour: J'ai cherché sur ce terme et je n'ai pas trouvé de réponse définitive, seulement quelques questions. J'ai donc pensé que je le posterais).
Système:
164638.058 :[ Full GC (Système) [PSYoungGen: 22789 K- > 0 K(992448 K)] [PSOldGen: 1645508K->1666990K(2097152K)] 1668298K->1666990K(3089600K) [PSPermGen: 164914 K - >164914 K (166720 K)], 5.7499132 secondes] [Fois: utilisateur = 5.69 sys=0.06, réel=5.75 secondes]
Pas De Système:
166687.013 :[ Plein GC [PSYoungGen: 126501K- > 0K (922048K)] [PSOldGen: 2063794K->1598637K(2097152K)] 2190295K->1598637K(3019200K) [PSPermGen: 165840 K - >164249 K (166016 K)], 6.8204928 secondes] [Fois: utilisateur=6.80 sys=0.02, réel=6.81 secondes]
Options du GC
Nos options de mémoire java liées au gc sont: - Xloggc:../serveur/pe/log/jvm_gc.journal -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
Nous ne faisons pas '-XX:+DisableExplicitGC', il est donc possible qu'une classe errante appelle System.gc ()
Fwiw, nos options jvm complètes:
-Xms3072m -Xmx3072m -XX:+HeapDumpOnOutOfMemoryError -XX:-UseGCOverheadLimit -Xloggc:../serveur/pe/log/jvm_gc.log-XX: + PrintGCTimeStamps -XX: + PrintGCDetails-XX: MaxPermSize=256m-XX: + UseCompressedOops
Merci d'avance,
Va
2 answers
De la source pour OpenJDK, je dirais que c'est
const bool is_system_gc = gc_cause == GCCause::_java_lang_system_gc;
// This is useful for debugging but don't change the output the
// the customer sees.
const char* gc_cause_str = "Full GC";
if (is_system_gc && PrintGCDetails) {
gc_cause_str = "Full GC (System)";
}
J'ai créé une version personnalisée de la classe d'exécution pour enregistrer le nom du thread et la trace de la pile dans un fichier à chaque exécution.getRuntime ().gc() a été appelé. (Système.gc () appelle ceci) Je l'ai trouvé utile pour traquer et supprimer de tels appelants.
Un endroit où cela se produit est au soleil.misc.Classe GC. Le RMI demandera à cette classe de s'assurer qu'un GC a fonctionné dans les N dernières secondes. S'il n'y a pas eu de GC il déclenche un plein GC.
Cela ne s'affiche comme un problème que si vous réduisez le nombre de GCS mineurs. Ironiquement, cela peut signifier que vous obtenez plus de GCS complets. ;)
Je n'utilise pas RMI (sauf peut-être JConsole) Donc je l'ai réglé sur une semaine. (Pensez que la valeur par défaut est une heure)
-Dsun.rmi.dgc.server.gcInterval=604800000
-Dsun.rmi.dgc.client.gcInterval=604800000
Je teste le GC explicite sur mon mac, il affiche "Full GC (System)" lors de l'utilisation de jdk 1.6, mais affiche "Full GC" avec jdk 1.7
Ne vous fiez donc pas à l'étiquette "Système" lorsque vous syntonisez le journal GC, sauf si vous connaissez exactement l'environnement d'exécution et le numéro de version jdk