Comment réduire les longues pauses de la GC – Monter un serveur MineCraft

Les longues pauses GC ne sont pas souhaitables pour les applications. Cela a une incidence sur vos contrats de niveau de service, sur les expériences des clients et sur les applications critiques. Ainsi, dans cet article, j'ai exposé les principales raisons pouvant conduire à de longues pauses GC, ainsi que les solutions possibles pour les résoudre.

1. Taux de création d'objets élevé

Si le taux de création d’objets de votre application est très élevé, le taux de récupération de place sera également très élevé. Un taux élevé de collecte des déchets augmentera également le temps de pause du CPG. Ainsi, l'optimisation de l'application pour créer moins d'objets constitue la stratégie THE EFFECTIVE pour réduire les longues pauses GC. Cela peut prendre beaucoup de temps, mais cela en vaut la peine. Afin d'optimiser le taux de création d'objets dans l'application, vous pouvez envisager d'utiliser des profileurs Java tels que JProfiler, YourKit ou JVisualVM. Ces profileurs rapporteront:

• Quels sont les objets qui ont été créés?

• Quelle est la vitesse à laquelle ces objets sont créés?

• Quelle est la quantité d’espace qu’ils occupent en mémoire?

• Qui les crée?

Essayez toujours d’optimiser les objets qui occupent le plus de mémoire. Allez après le gros poisson dans l'étang.

Idée: comment déterminer le taux de création d'objets

Téléchargez votre journal GC vers l'outil d'analyse de journal Universal Garbage Collection, GCeasy. Cet outil indiquera le taux de création d'objet. Il y aura un champ par son nom "Taux de création moyen" dans la section "Statistiques d'objet". Ce champ indique le taux de création d'objet. Efforcez-vous de garder cette valeur plus basse. Voir l’image (qui est un extrait du rapport généré par GCeasy) montrant le "Taux de création moyen" à 8,83 mb.sec.

2. Jeune génération sous dimensionnée

Lorsque la jeune génération est sous-dimensionnée, les objets sont promus prématurément à l'ancienne génération. La collecte des déchets de l'ancienne génération prend plus de temps que celle de la jeune génération. Ainsi, augmenter la taille de la jeune génération peut potentiellement réduire les longues pauses GC. La taille de la jeune génération peut être augmentée en définissant l'un des deux arguments de la machine virtuelle Java

-Xmn: spécifie la taille de la jeune génération.

-XX: NewRatio: Spécifie la taille de la jeune génération par rapport à l’ancienne génération. Par exemple, si vous définissez -XX: NewRatio = 2, le rapport entre l'ancienne et la jeune génération est égal à 1: 2. La jeune génération aura la moitié de la taille de l’ensemble. Ainsi, si la taille du segment de mémoire est de 2 Go, la taille de la nouvelle génération sera de 1 Go.

3. Choix de l'algorithme GC

Votre algorithme CPG a une influence majeure sur le temps de pause du CPG. Si vous êtes un expert du GC ou avez l’intention de le devenir (ou si un membre de votre équipe est un expert du GC), vous pouvez régler les paramètres du GC pour obtenir un temps de pause optimal du GC. Si vous n’avez pas beaucoup d’expertise en GC, je vous recommanderais alors l’algorithme G1 GC en raison de sa syntonisation automatique aptitude. Dans G1 GC, vous pouvez définir l’objectif de temps de pause du GC à l’aide de la propriété système ‘-XX: MaxGCPauseMillis.’ Exemple:

    -XX: MaxGCPauseMillis = 200

Comme dans l'exemple ci-dessus, le temps de pause maximum du CPG est défini sur 200 millisecondes. JVM s’efforcera de l’atteindre.

4. Échange de processus

Parfois, en raison d’un manque de mémoire vive (RAM), le système d’exploitation pourrait échanger votre application depuis la mémoire. L'échange est très coûteux, car il nécessite des accès au disque, ce qui est beaucoup plus lent que l'accès à la mémoire physique. À mon humble avis, aucune application sérieuse dans un environnement de production ne devrait être échangée. Lorsque le processus est échangé, la GC prend beaucoup de temps.

Vous trouverez ci-dessous le script obtenu de StackOverflow (grâce à l'auteur) qui, une fois exécuté, affichera tous les processus en cours d'échange. Assurez-vous que votre processus ne soit pas échangé.

#! / bin / bash
# Obtenir l'utilisation actuelle de l'échange pour tous les processus en cours d'exécution
# Erik Ljungstrom 27/05/2011
# Modifié par Mikko Rantalainen 2012-08-09
# Dirige la sortie vers "sort -nk3" pour obtenir une sortie triée
# Modifié par Marc Methot 2014-09-18
# Suppression de la nécessité de sudo

SOMME = 0
GLOBAL = 0
pour DIR dans `find / proc / -maxdepth 1 -type d -regex" ^ / proc /[0-9]+ "`
faire
    PID = `echo $ DIR | cut -d / -f 3`
    PROGNAME = `ps -p $ PID -o comm --no-headers`
    pour SWAP dans `grep VmSwap $ DIR / status 2> / dev / null | awk 'print $ 2' `
    faire
        laisser SUM = $ SUM + $ SWAP
    terminé
    si (($ SUM> 0)); ensuite
        echo "PID = $ PID échangé $ SUM KB ($ PROGNAME)"
    Fi
    let OVERALL = $ OVERALL + $ SUM
    SOMME = 0
terminé
echo "Échange global utilisé: $ OVERALL KB"

Si vous constatez que vos processus sont en train de permuter, effectuez l'une des opérations suivantes:

• Allouez plus de RAM au service.

• Réduisez le nombre de processus en cours d'exécution sur le serveur afin qu'il puisse libérer de la mémoire (RAM).

• Réduisez la taille de votre application (ce que je ne recommanderais pas, car cela pourrait avoir d’autres effets secondaires. Cela pourrait quand même résoudre votre problème).

5. Réglage du nombre de threads GC

Pour chaque événement du GC signalé dans le journal du GC, les temps utilisateur, système et réel sont imprimés. Exemple:

[Times: user=25.56 sys=0.35, real=20.48 secs]

Pour connaître la différence entre chacun de ces moments, veuillez lire cet article. (Je vous encourage fortement à lire l'article avant de continuer cette section). Si, dans les événements du GC, vous remarquez constamment que le «temps réel» n’est pas sensiblement inférieur au temps «utilisateur», cela signifie peut-être qu’il n’ya pas assez de threads GC. Pensez à augmenter le nombre de threads GC. Supposons que le temps "utilisateur" soit de 25 secondes et que vous ayez configuré le nombre de threads du GC sur 5, alors que le temps réel devrait être proche de 5 secondes (car 25 secondes / 5 threads = 5 secondes).

AVERTISSEMENT: l'ajout d'un trop grand nombre de threads GC consomme beaucoup de temps processeur et prive de ressources de votre application. Par conséquent, vous devez effectuer des tests approfondis avant d’augmenter le nombre de threads du CPG.

6. Trafic IO d'arrière-plan

Si l'activité d'E / S du système de fichiers est importante (de nombreuses lectures et écritures sont en cours), cela peut également entraîner de longues pauses GC. Cette activité d'E / S importante du système de fichiers peut ne pas être provoquée par votre application. Peut-être est-il causé par un autre processus en cours d'exécution sur le même serveur. Néanmoins, votre application risque de subir de longues pauses GC. Voici un brillant article de LinkedIn Engineers qui décrit ce problème en détail.

En cas de forte activité d’entrée / sortie, vous remarquerez que le temps «réel» est nettement supérieur au temps «utilisateur». Exemple:

[Times: user=0.20 sys=0.01, real=18.45 secs]

Lorsque cela se produit, voici quelques solutions potentielles pour le résoudre:

• Si votre application génère une activité d'E / S élevée, optimisez-la.

• Éliminez les processus qui entraînent une activité d'E / S élevée sur le serveur.

• Déplacez votre application sur un autre serveur où l'activité d'E / S est moindre.

Idée: comment surveiller l'activité d'E / S

Vous pouvez surveiller l'activité des E / S à l'aide du sar (Rapport d'activité du système), dans Unix. Exemple:

sar -d -p 1

La commande ci-dessus indique les lectures / s et les écritures / s effectuées sur le périphérique toutes les secondes. Pour plus de détails sur la commande ‘sar’, reportez-vous à ce tutoriel.

7. Appels System.gc ()

Lorsque les appels de méthode System.gc () ou Runtime.getRuntime (). Gc () sont appelés, cela provoque des GC complets. Pendant les GC complètes stop-the-world, la machine virtuelle Java entière est gelée (c’est-à-dire qu’aucune activité de l’utilisateur ne sera effectuée pendant cette période). Les appels System.gc () proviennent d'une des sources suivantes:

1. Vos propres développeurs peuvent appeler explicitement la méthode System.gc ().
2. Il peut s'agir de bibliothèques tierces, de cadres ou parfois même de serveurs d'applications que vous utilisez. N'importe lequel d'entre eux pourrait invoquer la méthode System.gc ().
3. Il pourrait être déclenché à partir d'outils externes (tels que VisualVM) via l'utilisation de JMX.
4. Si votre application utilise RMI, RMI appelle System.gc () à intervalles réguliers. Cet intervalle peut être configuré à l'aide des propriétés système suivantes:

-Dsun.rmi.dgc.server.gcInterval = n

-Dsun.rmi.dgc.client.gcInterval = n

Déterminez s’il est absolument nécessaire d’appeler explicitement System.gc (). Si vous n'en avez pas besoin, supprimez-le. D'autre part, vous pouvez forcer la désactivation des appels System.gc () en passant l'argument JVM: –XX: + DisableExplicitGC. Pour plus de détails sur les problèmes liés à System.gc () et sur la solution, reportez-vous à cet article.

Tidbit: Comment savoir si les appels System.gc () sont appelés explicitement?

Téléchargez votre journal GC vers l'outil d'analyse de journal Universal Garbage Collection, GCeasy. Cet outil comporte une section intitulée "Causes du CPG". Si une activité du CPG est déclenchée en raison d’appels "System.gc ()", elle sera indiquée dans cette section. Voir l'image (qui est un extrait du rapport généré par GCeasy), montrant que System.gc () a été créé quatre fois au cours de la durée de vie de cette application.

MISE EN GARDE: Toutes les stratégies susmentionnées ne devraient être mises en production qu'après des tests et analyses approfondis. Toutes les stratégies peuvent ne pas s'appliquer à votre application. Une mauvaise utilisation de ces stratégies peut entraîner des résultats négatifs.