Java 7 (JDK 7) Collecte de mémoire et documentation sur G1
Java 7 est sorti depuis quelque temps déjà, mais je ne trouve aucune bonne ressource sur la configuration de garbage collectors, plus précisément de la nouvelle G1 collector =.
Mes questions:
- G1 est-il le collecteur par défaut dans Java 7 et si ce n’est pas le cas, comment puis-je activer G1?
- Quels sont les paramètres facultatifs de g1 dans Java7?
- Des modifications ont-elles été apportées à d'autres collecteurs tels que cms ou le collecteur parallèle dans Java 7?
- Où puis-je trouver une bonne documentation sur la récupération de place dans Java 7?
Le ramasse-miettes G1 n'est pas celui par défaut dans mon installation de Java, version 1.7.0_01. Vous pouvez voir par vous-même en utilisant des options de ligne de commande supplémentaires:
> Java -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -version
-XX:InitialHeapSize=132304640 -XX:MaxHeapSize=2116874240 -XX:ParallelGCThreads=4 -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
Java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)
Heap
PSYoungGen total 37696K, used 1293K [0x00000007d5eb0000, 0x00000007d88c0000, 0x0000000800000000)
eden space 32320K, 4% used [0x00000007d5eb0000,0x00000007d5ff3408,0x00000007d7e40000)
from space 5376K, 0% used [0x00000007d8380000,0x00000007d8380000,0x00000007d88c0000)
to space 5376K, 0% used [0x00000007d7e40000,0x00000007d7e40000,0x00000007d8380000)
PSOldGen total 86144K, used 0K [0x0000000781c00000, 0x0000000787020000, 0x00000007d5eb0000)
object space 86144K, 0% used [0x0000000781c00000,0x0000000781c00000,0x0000000787020000)
PSPermGen total 21248K, used 2032K [0x000000077ca00000, 0x000000077dec0000, 0x0000000781c00000)
object space 21248K, 9% used [0x000000077ca00000,0x000000077cbfc288,0x000000077dec0000)
Vous n'avez plus besoin d'activer les options expérimentales pour activer le collecteur G1, cependant:
> Java -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseG1GC -version
-XX:InitialHeapSize=132304640 -XX:MaxHeapSize=2116874240 -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseCompressedOops -XX:+UseG1GC -XX:-UseLargePagesIndividualAllocation
Java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)
Heap
garbage-first heap total 130048K, used 0K [0x000000077ca00000, 0x0000000784900000, 0x00000007fae00000)
region size 1024K, 1 young (1024K), 0 survivors (0K)
compacting perm gen total 20480K, used 2032K [0x00000007fae00000, 0x00000007fc200000, 0x0000000800000000)
the space 20480K, 9% used [0x00000007fae00000, 0x00000007faffc288, 0x00000007faffc400, 0x00000007fc200000)
No shared spaces configured.
Je ne sais pas où vous pouvez trouver une bonne documentation.
Oracle a finalement rendu G1 officiel dans Java 7 U4: http://www.Oracle.com/technetwork/Java/javase/7u4-relnotes-1575007.html
Description: http://docs.Oracle.com/javase/7/docs/technotes/guides/vm/G1.html
Options de ligne de commande: http://www.Oracle.com/technetwork/Java/javase/tech/vmoptions-jsp-140102.html#G1Options
Néanmoins, je ne pense pas que ce soit le collecteur par défaut dans Java 7.). Pour les serveurs, la valeur par défaut est Parallel Collector, comme dans Java 6.
Oui, G1 est le nouveau ramasse-miettes standard dans la JVM Java 1.7.
Ici vous pouvez trouver beaucoup d’informations sur l’utilisation et la configuration du nouveau ramasse-miettes:
Utilisation de G1 G1 est toujours considéré comme expérimental et peut être activé avec les deux paramètres suivants:
-XX: + UnlockExperimentalVMOptions -XX: + UseG1GC
Pour définir un objectif de temps de pause du GC, utilisez le paramètre suivant:
-XX: MaxGCPauseMillis = 50 (pour un temps de pause cible de 50 ms)
Avec G1, il est possible de spécifier un intervalle de temps pendant lequel une pause GC ne doit pas durer plus longtemps que le temps indiqué ci-dessus:
-XX: GCPauseIntervalMillis = 200 (pour une cible d'intervalle de pause de 200 ms)
Notez que les deux options ci-dessus représentent des objectifs et non des promesses ou des garanties. Ils pourraient bien fonctionner dans certaines situations mais pas dans d'autres, et le GC pourrait ne pas toujours être en mesure de leur obéir.
Alternativement, la taille de la jeune génération peut être spécifiée explicitement pour avoir un impact sur les temps de pause d'évacuation:
-XX: + G1YoungGenSize = 512m (pour une jeune génération de 512 mégaoctets)
G1 utilise également l'équivalent d'espaces survivants, qui sont naturellement un ensemble de régions (potentiellement non contiguës). Leur taille peut être spécifiée avec les paramètres habituels (par exemple, -XX: SurvivorRatio = 6).
Enfin, pour exploiter pleinement le potentiel de G1, essayez de définir ces deux paramètres actuellement désactivés par défaut, car ils risquent de révéler une condition de concurrence rare:
-XX: + G1ParallelRSetUpdatingEnabled -XX: + G1ParallelRSetScanningEnabled
Une dernière chose à noter est que G1 est très détaillé par rapport aux autres GC HotSpot lorsque -XX: + PrintGCDetails est défini. En effet, il imprime les synchronisations par thread-GC et d'autres informations très utiles pour le profilage et le dépannage. Si vous souhaitez un journal GC plus concis, passez à l’utilisation de -verbosegc (bien qu’il soit recommandé d’obtenir le journal GC plus détaillé).
J'ai également trouvé l'article this très utile pour comprendre les entrailles de G1.
Encore plus d'informations ici .
1. G1 est-il le collecteur par défaut de Java 7 (...)
La règle sur cette Java 5 page est toujours applicable dans Java 7 (et autant que je sache, Java 8):
Sur classe-serveur sur les machines exécutant la machine virtuelle du serveur, le ramasse-miettes (GC) est passé du collecteur série précédent (-XX: + UseSerialGC) à un collecteur parallèle (-XX: + UseParallelGC). .
Mais considérez aussi:
- Les machines virtuelles Java 64 bits ne sont pas fournies avec une machine virtuelle
-client, Elles sont donc toujours "classe de serveur" - Depuis Java 7, l'utilisation de -XX: + UseParallelGC (qu'elle soit définie ou implicite) implique également -XX: + UseParallelOldGC (c'est-à-dire, sauf si explicitement désactivé)
Par exemple, si vous exécutez Windows x64 ...
- Java 7 64 bits, vous obtenez Parallel GC (pour les générations les plus jeunes et les plus âgées) par défaut.
- Java 8 32 bits, vous obtenez Serial GC (pour les deux générations) par défaut
1. (...) comment activer G1?
À partir de Java 7, simplement -XX:+UseG1GC. Peut-être aussi intéressant est quand vous voudriez:
Les applications fonctionnant aujourd'hui avec le CMS ou le collecteur de mémoire ParallelOld gagneraient à passer à G1 si l'application possède un ou plusieurs des traits suivants.
- Plus de 50% du segment Java est occupé par des données actives.
- Le taux d'allocation ou de promotion d'un objet varie considérablement.
- Collecte d'ordures longue non souhaitée ou pauses de compactage (plus de 0,5 à 1 seconde)
2. Quels sont les paramètres facultatifs de g1 dans Java7?
Je n'ai pas utilisé G1 moi-même, mais je suppose qu'il adhère au même indicateur de base "débit/ergonomique" utilisé pour régler les autres collecteurs parallèles. D'après mon expérience avec le CPG parallèle, -XX:GCTimeRatio A été décisif pour fournir le compromis vitesse-mémoire attendu. YMMV.
Les options spécifiques à G1 sont listées ici
3. Des modifications ont-elles été apportées à (...) cms ou au collecteur parallèle dans Java 7?
Je ne sais pas, mais ...
G1 est prévu pour remplacer à long terme le Collecteur Mark-Sweep (CMS) simultané
4. Où puis-je trouver une bonne documentation sur la récupération de place dans Java 7?
Cela peut être pénible à trouver, n'est-ce pas? La meilleure page "hub" que j'ai trouvée est probablement celle-ci:
http: //www.Oracle.com/technetwork/Java/javase/tech/index-jsp-140228.html
Un peu de lecture en profondeur est nécessaire, mais cela en vaut la peine si vous avez besoin de faire quelques ajustements. Ce qui est particulièrement intéressant est: Ergonomie du ramasse-miettes
- G1 est-il le collecteur par défaut dans Java 7 et si ce n’est pas le cas, comment puis-je activer G1?
G1 n'est pas un collecteur par défaut dans Java 7. -XX:+UseG1GC va activer G1GC
- Quels sont les paramètres facultatifs de g1 dans Java7?
Il y a beaucoup de. Consultez cet article Oracle pour des informations complètes.
Le GC G1 est un collecteur de déchets adaptatif avec des valeurs par défaut qui lui permettent de fonctionner efficacement sans modification.
Pour cette raison, personnalisez les paramètres critiques
-XX:MaxGCPauseMillis
-XX:G1HeapRegionSize
-XX:ParallelGCThreads
-XX:ConcGCThreads
et laissez tous les autres paramètres à leur valeur par défaut.
Voici une liste des options importantes et leurs valeurs par défaut. Cette liste s’applique à la dernière Java HotSpot VM, version 24.). Vous pouvez adapter et ajuster les paramètres G1 GC sur la ligne de commande de la JVM.
Valeurs par défaut importantes:
-XX:G1HeapRegionSize=n
Définit la taille d'une région G1. La valeur sera une puissance de deux et peut aller de 1 Mo à 32 Mo. L’objectif est d’avoir environ 2048 régions basées sur la taille minimale du tas Java).
-XX:MaxGCPauseMillis=200
Définit une valeur cible pour le temps de pause maximum souhaité. La valeur par défaut est 200 millisecondes. La valeur spécifiée ne s'adapte pas à la taille de votre tas.
-XX:G1NewSizePercent=5
Définit le pourcentage du tas à utiliser comme minimum pour la taille de la jeune génération. La valeur par défaut est 5% de votre segment de mémoire Java.
-XX:G1MaxNewSizePercent=60
Définit le pourcentage de la taille de segment de mémoire à utiliser comme maximum pour la taille de la jeune génération. La valeur par défaut est 60% de votre segment de mémoire Java.
-XX:ParallelGCThreads=n
Définit la valeur des threads de travail STW. Définit la valeur de n sur le nombre de processeurs logiques. La valeur de n correspond au nombre de processeurs logiques jusqu’à une valeur de 8.
S'il y a plus de huit processeurs logiques, définit la valeur de n sur environ 5/8 des processeurs logiques. Cela fonctionne dans la plupart des cas, sauf pour les systèmes plus grands SPARC où la valeur de n peut être d'environ 5/16 des processeurs logiques).
-XX:ConcGCThreads=n
Définit le nombre de threads de marquage en parallèle. Définit n à environ 1/4 du nombre de threads de la récupération de place parallèles (ParallelGCThreads).
-XX:InitiatingHeapOccupancyPercent=45
Définit le seuil d'occupation de segment de mémoire Java) qui déclenche un cycle de marquage. L'occupation par défaut correspond à 45% du segment de mémoire total Java.
-XX:G1MixedGCLiveThresholdPercent=65
Définit le seuil d’occupation d’une ancienne région à inclure dans un cycle de récupération de place mixte. L'occupation par défaut est de 65%
-XX:G1HeapWastePercent=10
Définit le pourcentage de tas que vous êtes prêt à gaspiller. Le Java HotSpot VM ne lance pas le cycle de récupération de place mixte lorsque le pourcentage récupérable est inférieur au pourcentage de perte de mémoire)
-XX:G1MixedGCCountTarget=8
Définit le nombre cible de collectes de mémoire mixtes après un cycle de marquage pour collecter les anciennes régions contenant au plus des données actives G1MixedGCLIveThresholdPercent. La valeur par défaut est 8 collectes de déchets mixtes
-XX:G1OldCSetRegionThresholdPercent=10
Définit une limite supérieure sur le nombre d'anciennes régions à collecter au cours d'un cycle de collecte de déchets mixte. La valeur par défaut est 10% du segment de mémoire Java
-XX:G1ReservePercent=10
Définit le pourcentage de mémoire de réserve à garder libre afin de réduire le risque de débordement dans l’espace. La valeur par défaut est 10%. Lorsque vous augmentez ou diminuez le pourcentage, veillez à ajuster le tas total Java du même montant).
Vous avez reconfiguré de nombreux paramètres G1GC, qui ne sont pas nécessaires si vous suivez la page de documentation ci-dessus. Veuillez vérifier les recommandations ci-dessus, en particulier sur ParallelGCThreads et ConcGCThreads , qui sont être basé sur vos cœurs de processeur. Supprimez la reconfiguration des paramètres inutiles.
Recommandations d'Oracle:
Lorsque vous évaluez et peaufinez le CPG G1, tenez compte des recommandations suivantes:
Taille de la jeune génération : évitez de définir explicitement la taille de la jeune génération avec le
-Xmnoption ou toute autre option associée telle que-XX:NewRatio. La fixation de la taille de la jeune génération annule l'objectif de temps de pause cible.Objectifs de temps de pause: Lorsque vous évaluez ou optimisez un ramasse-miettes, il existe toujours un compromis latence-débit. Le GC G1 est un récupérateur de mémoire incrémentiel avec des pauses uniformes, mais également plus de charge sur les threads de l'application. L'objectif de débit pour le CPG G1 est un temps d'application de 90% et un temps de récupération des déchets de 10%.
- Des modifications ont-elles été apportées à d'autres collecteurs tels que cms ou le collecteur parallèle dans Java 7?
Il y a quelques changements avec Java 7. Regardez ceci article
- Où puis-je trouver une bonne documentation sur la récupération de place dans Java 7?
Reportez-vous à la page de documentation Oracle sur gc et à la question SE correspondante:
Non G1 n'est pas un ramasse-miettes par défaut dans jdk 1.7.0_02. Le ramasse-miettes par défaut dépend de la classe de machine. Si la machine appartient à la classe Server, le collecteur de place par défaut est Throughput Collector. Si la machine appartient à la classe Client, le collecteur de place par défaut est Serial Collector.
La documentation disponible à l’adresse http://www.Oracle.com/technetwork/Java/javase/tech/g1-intro-jsp-135488.html (le lien fourni par Wojtek) semble être le seul lien officiel avec info mais l'info semble obsolète car certains des drapeaux mentionnés n'étaient disponibles que dans les versions de test, ils n'existent plus dans les versions de production. Une personne d’Oracle devrait fournir une documentation mise à jour sur le CPG G1.
Par défaut, vous ne voulez pas vraiment utiliser le collecteur G1, car ce n'est pas vraiment meilleur que les autres. C'est seulement bon pour des buts spéciaux.
En cas de faible latence, l’application est légèrement meilleure que le système de gestion de contenu, car elle dispose de temps de pause un peu plus courts et plus prévisibles. En échange, le débit est bien pire que le CMS en échange.
Ce n'est donc bon que si la latence est importante, mais le débit n'est pas important du tout. Si les deux sont importants, restez avec CMS.