Limite supérieure du GC dépassée

93

Quelle est la durée d'échantillonnage utilisée par la JVM pour lancer «java.lang.OutOfMemoryError: limite de surcharge GC dépassée»? Je sais que vous pouvez contrôler 98% et 2% avec les paramètres GCTimeLimit et GCHeapFreeLimit mais quel est le temps d'échantillonnage?

PRK
la source

Réponses:

82

À partir de Java SE 6 HotSpot [tm] Réglage de la récupération de place de la machine virtuelle

le suivant

Temps GC excessif et OutOfMemoryError

Le collecteur simultané lèvera une OutOfMemoryError si trop de temps est passé dans le garbage collection: si plus de 98% du temps total est passé dans le garbage collection et que moins de 2% du tas est récupéré, une OutOfMemoryError sera levée. Cette fonctionnalité est conçue pour empêcher les applications de s'exécuter pendant une période prolongée tout en effectuant peu ou pas de progrès car le tas est trop petit. Si nécessaire, cette fonctionnalité peut être désactivée en ajoutant l'option -XX: -UseGCOverheadLimit à la ligne de commande.

La politique est la même que celle du collecteur parallèle, sauf que le temps passé à effectuer des collectes simultanées n'est pas compté dans la limite de temps de 98%. En d'autres termes, seules les collectes effectuées alors que l'application est arrêtée comptent pour un temps GC excessif. De telles collectes sont généralement dues à un échec du mode concurrent ou à une demande de collecte explicite (par exemple, un appel à System.gc ()).

en conjonction avec un passage plus bas

L'une des utilisations les plus courantes du garbage collection explicite se produit avec le garbage collection distribué (DGC) RMI. Les applications utilisant RMI font référence à des objets dans d'autres machines virtuelles. Les déchets ne peuvent pas être collectés dans ces applications distribuées sans collecter occasionnellement le tas local, donc RMI force périodiquement des collectes complètes. La fréquence de ces collectes peut être contrôlée avec des propriétés. Par exemple,

java -Dsun.rmi.dgc.client.gcInterval=3600000

-Dsun.rmi.dgc.server.gcInterval=3600000 spécifie une collecte explicite une fois par heure au lieu du taux par défaut d'une fois par minute. Cependant, cela peut également entraîner la récupération de certains objets beaucoup plus longs. Ces propriétés peuvent être définies aussi haut que Long.MAX_VALUE pour rendre le temps entre les collections explicites effectivement infini, si vous ne souhaitez pas une limite supérieure sur l'actualité de l'activité DGC.

Cela semble impliquer que la période d'évaluation pour déterminer les 98% est d'une minute, mais elle peut être configurable sur la JVM de Sun avec la bonne définition.

Bien entendu, d'autres interprétations sont possibles.

Edwin Buck
la source
5
Le garbage collection distribué RMI est une activité indépendante du garbage collection régulier. Donc je ne vois pas comment vous pouvez déduire ce que vous venez de faire.
Stephen C
2
L'inférence n'est ni parfaite ni même correcte, c'est pourquoi «semble impliquer» est utilisé au lieu de «implique». Si vous êtes d'accord avec l'observation que si les gens de Sun ont utilisé une minute pour déterminer l'intervalle de collecte des ordures pour RMI, ce temps de collecte dans la collecte simultanée n'est calculé que lorsque le programme principal s'arrête et fait un peu un acte de foi , alors les chances sont bonnes, les 98% sont collectés en une minute. C'est un nombre magique, mais une minute est un nombre magique souvent utilisé par rapport à 3,5 minutes.
Edwin Buck
@StephenC voulez-vous dire que même si nous le définissons, -XX:+DisableExplicitGC cela n'aura pas d'impact sur la configuration liée à RMI et le système invoquera gc dans la fréquence définie avec le paramètre-Dsun.rmi.dgc.server.gcInterval
Steephen
1
@Steephen - Non. Ce n'est pas ce que je dis. Je parle de cette déclaration: " Cela semble impliquer que la période d'évaluation pour déterminer les 98% est d'une minute ..." . Et notez qu'Edwin convient que l'inférence est «imparfaite». La déduction est basée sur l'hypothèse que les gens de Sun qui ont mis en œuvre RMI (& DGC) étaient en étroite communication avec les gens qui ont mis en œuvre le mécanisme de limitation des frais généraux du GC. Je soupçonne que les deux développements se sont effectivement produits à des moments différents. Notez que la -Dsun.rmi.dgc.server.gcIntervalpropriété existe depuis Java 1.2.
Stephen C
1
Quoi qu'il en soit, une meilleure approche pour trouver la vraie réponse à cette question serait de regarder le code source d'OpenJDK.
Stephen C