Construisez un déambulateur en fonte sur Spring Boot et AppCDS

Partage de données de classe d'application (AppCDS) - Fonction JVM pour accélérer le démarrage et économiser de la mémoire. Après être apparu à ses débuts dans HotSpot dans JDK 1.5 (2004), il est resté longtemps très limité, et même partiellement commercial. Ce n'est qu'avec OpenJDK 10 (2018) qu'il a été mis à la disposition de simples mortels, tout en élargissant le champ d'application. Et récemment, Java 13 a essayé de simplifier cette application.

L'idée d'AppCDS est de «partager» des classes une fois chargées entre des instances de la même machine virtuelle Java sur le même hôte. Il semble que cela devrait être idéal pour les microservices, en particulier les "broilers" sur Spring Boot avec leurs milliers de classes de bibliothèque, car maintenant ces classes n'auront plus besoin d'être chargées (analysées et vérifiées) à chaque démarrage de chaque instance JVM, et elles ne seront pas dupliquées en mémoire. Cela signifie que le lancement devrait devenir plus rapide et la consommation de mémoire devrait être inférieure. Merveilleux, non?

Tout est ainsi, tout est ainsi. Mais si vous, l'odnokhabryanin, ne croyiez pas aux panneaux du boulevard, mais aux chiffres et aux exemples spécifiques, alors bienvenue à Kat - essayons de comprendre comment c'est vraiment ...

Au lieu de l'avertissement

Avant vous n'est pas un guide d'utilisation d'AppCDS, mais un résumé des résultats d'une petite étude. J'étais intéressé à comprendre comment cette fonction JVM est applicable dans mon projet de travail, et j'ai essayé de l'évaluer du point de vue d'un développeur d'entreprise, en exposant le résultat dans cet article. Cela n'incluait pas des sujets tels que l'utilisation d'AppCDS sur le chemin du module, l'implémentation d'AppCDS sur d'autres machines virtuelles (pas HotSpot) et les subtilités de l'utilisation des conteneurs. Mais il y a une partie théorique pour explorer le sujet, ainsi qu'une partie expérimentale écrite pour que vous puissiez répéter l'expérience vous-même. Aucun résultat n'a encore été appliqué en production, mais qui sait à quoi ressemblera demain ...

Théorie

Une brève introduction à AppCDS

La connaissance de ce sujet peut avoir eu lieu dans plusieurs sources, par exemple:

• dans un article de Nikolai Parlog (y compris Java 13 buns, mais sans Spring Boot)
• dans un rapport et un article de Volker Simonis (sans Java 13, mais avec des détails)
• dans un rapport de l' auteur de ces lignes (sans Java 13, mais en mettant l'accent sur Spring Boot)

Afin de ne pas me lancer dans une nouvelle narration, je ne soulignerai que quelques points importants pour cet article.

Tout d'abord, AppCDS est une extension de la fonction CDS qui est apparue depuis longtemps dans HotSpot, dont l'essence est la suivante:

Pour donner vie aux deux idées, vous devez procéder comme suit (en termes généraux):

1. Obtenez une liste des classes que vous souhaitez partager entre les instances d'application
2. Fusionnez ces classes dans une archive adaptée au mappage de la mémoire
3. Connectez l'archive à chaque instance de l'application au démarrage

Il semblerait que l'algorithme ne soit que 3 étapes - prenez-le et faites-le. Mais ici commence la nouvelle, toutes sortes de choses.

La mauvaise chose est que dans le pire des cas, chacun de ces éléments se transforme en au moins un lancement JVM avec ses propres options spécifiques, ce qui signifie que l'algorithme entier est un jonglage subtil du même type d'options et de fichiers. Cela ne semble pas très prometteur, n'est-ce pas?

Mais il y a une bonne nouvelle: les travaux d'amélioration de cet algorithme sont en cours , et à chaque version de Java, son application devient plus simple. Ainsi, par exemple:

• Dans OpenJDK 10 et 11, vous pouvez ignorer l'étape 1 si vous souhaitez partager uniquement les classes JDK principales, car elles ont déjà été compilées pour nous et placées dans $JAVA_HOME\lib\classlist (≈1200 pcs.).
• Dans OpenJDK 12, vous pouvez ignorer l' étape 2 , car avec la liste des classes, l'archive de distribution comprend également une archive prête à l'emploi avec eux, qui est utilisée prête à l'emploi et ne nécessite pas de connexion explicite.
• Au cas où vous souhaiteriez partager tout le reste (et le souhaitez généralement)
  OpenJDK 13 fournit des archives Dynamic CDS - des archives qui sont collectées pendant le fonctionnement de l'application et enregistrées lors de la dotation en personnel. Cela vous permet de réduire les points 1 et 2 en un point pas trop confus (bien que tout ne soit pas si simple, mais plus à ce sujet plus tard).

Ainsi, quel que soit le processus de préparation d'AppCDS, les 3 étapes énumérées ci-dessus sont toujours derrière, juste dans certains cas, elles sont voilées.

Comme vous l'avez probablement remarqué, avec l'avènement d'AppCDS, de nombreuses classes d'application commencent une double vie: elles vivent simultanément dans leurs anciens emplacements (le plus souvent des fichiers JAR) et dans une nouvelle archive partagée. Dans le même temps, le développeur continue de les modifier / supprimer / compléter au même endroit, et la JVM les reprend de la nouvelle lorsqu'elle fonctionne. Il n'est pas nécessaire d'être un devin pour voir le danger d'une telle situation: si rien n'est fait, tôt ou tard des copies des cours se corrodent, et nous obtiendrons de nombreux charmes de «l'enfer JAR» typique. Il est clair que la JVM ne peut pas empêcher les changements de classe, mais elle devrait être capable de détecter un écart dans le temps. Cependant, faire cela en comparant les classes par paires, même par des sommes de contrôle, est une idée; il peut annuler le reste des gains de productivité. C'est probablement pourquoi les ingénieurs JVM n'ont pas sélectionné les classes individuelles comme objet de comparaison, mais tout le chemin de classe, et ont déclaré dans la documentation AppCDS: "Le chemin de classe lors de la création d'une archive partagée doit être le même (ou au moins un préfixe) que lors des lancements ultérieurs de l'application."

Notez que le chemin de classe utilisé au moment de la création de l'archive doit être le même que (ou un préfixe) le chemin de classe utilisé au moment de l'exécution.

Mais ce n'est pas une déclaration sans ambiguïté, car, comme vous vous en souvenez, un chemin de classe peut être formé de différentes manières, telles que:

• lire des fichiers .class nus à partir de répertoires de packages compilés,
  par exemple java com.example.Main
• l'analyse des répertoires avec des fichiers JAR lors de l'utilisation de caractères génériques,
  par exemple java -cp mydir/* com.example.Main
• liste explicite des fichiers JAR et / ou ZIP,
  par exemple java -cp lib1.jar;lib2.jar com.example.Main

(sans parler du fait que le -cp/-classpath/--class-path peut également être défini différemment, par exemple via les options JVM -cp/-classpath/--class-path , la CLASSPATH environnement CLASSPATH ou l'attribut du fichier JAR Class-Path à lancer)

Parmi ces méthodes, une seule est prise en charge dans AppCDS - énumération explicite des fichiers JAR. Apparemment, les ingénieurs HotSpot JVM ont estimé que la comparaison des chemins de classe dans l'archive AppCDS et dans l'application lancée ne serait suffisamment rapide et fiable que s'ils étaient spécifiés aussi clairement que possible - avec une liste exhaustive habituelle.

CDS / AppCDS prend en charge l'archivage des classes à partir de fichiers JAR uniquement.

Il est important de noter ici que cette déclaration n'est pas récursive, c'est-à-dire ne s'applique pas aux fichiers JAR à l'intérieur des fichiers JAR (sauf s'il s'agit de Dynamic CDS, voir ci-dessous). Cela signifie que les poupées JAR habituelles émises par Spring Boot ne fonctionneront pas comme ça avec AppCDS normal, vous devrez vous asseoir.

Un autre inconvénient du travail de CDS est que les archives partagées sont projetées sur la mémoire avec des adresses fixes (commençant généralement à 0x800000000 ). En soi, ce n'est pas mauvais, mais comme la randomisation de la disposition de l'espace d'adressage (ASLR) est activée par défaut sur la plupart des systèmes d'exploitation, la plage de mémoire requise peut être partiellement occupée. Dans ce cas, la -Xshare HotSpot fait l’ option spéciale -Xshare qui prend en charge trois valeurs:

• -Xshare:on - force CDS / AppCDS; si la plage est occupée, la JVM se termine avec une erreur. Ce mode n'est pas recommandé pour une utilisation en production , car cela peut entraîner des plantages sporadiques lors du lancement des applications.
• -Xshare:off - (vous) changez de CDS / AppCDS; désactive complètement l'utilisation des données partagées (y compris les archives intégrées)
• -Xshare:auto - le comportement par défaut de la JVM lorsqu'elle, en cas d'impossibilité d'allouer la plage de mémoire requise, se rend discrètement et charge les classes comme d'habitude

Au moment de la rédaction de cet article, Oracle s'efforce simplement de résoudre ces problèmes, mais aucun numéro de version n'a encore été attribué.

Ces options nous sont partiellement utiles plus tard, mais pour l'instant, regardons ...

Applications AppCDS

Il existe plusieurs façons d'utiliser AppCDS. ruine ta vie optimiser le travail des microservices. Leur complexité et leur profit potentiel varient considérablement. Il est donc important de décider immédiatement lequel sera discuté plus tard.

Le plus simple est de ne pas utiliser même AppCDS, mais seulement CDS - c'est lorsque seules les classes de plate-forme entrent dans l'archive partagée (voir "Une brève introduction à AppCDS"). Nous supprimerons cette option immédiatement, car lorsqu'elle est appliquée aux microservices sur Spring Boot, elle donne trop peu de profit. Cela peut être vu par la proportion du nombre de classes partagées dans leur distribution générale en utilisant l'exemple d'un vrai microservice (voir le segment vert):

Plus complexe, mais prometteur est l'utilisation d'AppCDS à part entière, c'est-à-dire l'inclusion des classes de bibliothèque et d'application dans la même archive. Il s'agit de toute une famille d'options dérivées de combinaisons du nombre d'applications participantes et du nombre d'instances. Voici les évaluations subjectives de l'auteur sur les avantages et les difficultés de diverses applications d'AppCDS.

Faites attention:

• Dans l'application à une application dans une instance (n ° 1), le gain de mémoire peut s'avérer nul ou même négatif (surtout lors de la mesure sous Windows )
• La création de l'archive partagée correcte nécessite des actions, dont la complexité ne dépend pas du nombre de copies que l'application sera ensuite lancée (comparer les paires d'options n ° 1-2 et n ° 3-4)
• Dans le même temps, le passage d'une instance à plusieurs donne évidemment une augmentation du bénéfice pour les deux indicateurs, mais n'affecte pas la complexité de la préparation.

Dans cet article, nous n'atteindrons que l'option n ° 2 (à travers le n ° 1), car elle est assez simple pour une connaissance approfondie d'AppCDS et seulement pour elle sans astuces supplémentaires, nous pouvons utiliser les archives JEP-350 Dynamic CDS récemment publiées, que je veux ressentir en action.

Archives dynamiques du CDS

Les archives dynamiques CDS JEP-350 , l'une des principales innovations de Java 13, sont conçues pour simplifier l'utilisation d'AppCDS. Pour ressentir la simplification, vous devez d'abord comprendre la complexité. Permettez-moi de vous rappeler que l'algorithme d'application «propre» classique pour AppCDS se compose de 3 étapes: (1) obtenir une liste des classes partagées, (2) créer une archive à partir de celles-ci, et (3) exécuter l'application avec l'archive connectée. De ces étapes, seule la 3ème est réellement utile, le reste ne fait que la préparer. Et bien que l'obtention d'une liste de classes (étape # 1) puisse sembler très simple (dans certains cas, ce n'est même pas nécessaire), en fait lorsque vous travaillez avec des applications non triviales, cela s'avère être le plus difficile, en particulier en ce qui concerne Spring Boot. Le JEP-350 est donc nécessaire juste pour éliminer cette étape, ou plutôt l'automatiser. L'idée est que la JVM elle-même dresse une liste des classes dont l'application a besoin, puis forme elle-même l'archive dite «dynamique». D'accord, ça sonne bien. Mais le hic, c'est que maintenant il devient difficile de savoir à quel moment cesser d'accumuler des classes et procéder à leur placement dans l'archive. Auparavant, dans l'AppCDS classique, nous avions choisi un tel moment nous-mêmes et pouvions même coincer entre ces actions pour changer quelque chose dans la liste des classes avant de le transformer en archive. Maintenant, cela se produit automatiquement et seulement à un moment, pour lequel les ingénieurs JVM ont peut-être choisi la seule option de compromis - l'arrêt régulier de la JVM. Cela signifie que l'archive ne sera pas créée avant l'arrêt de l'application. Cette solution a deux conséquences importantes:

• En cas de plantage de la JVM, l'archive ne sera pas créée, quelle que soit la beauté de la liste des classes accumulées d'ici là (vous ne pouvez pas l'extraire plus tard en utilisant des moyens réguliers).
• L'archive sera créée uniquement à partir des classes qui ont réussi à se charger pendant la session d'application. Pour les applications Web, cela signifie que la création d'une archive en démarrant et en s'arrêtant là n'est pas correcte, car alors de nombreuses classes importantes n'entreront pas dans l'archive. Il est nécessaire d'exécuter au moins une requête HTTP sur l'application (et il est préférable de l'exécuter correctement dans tous les scénarios) afin que toutes les classes qu'elle utilise réellement soient chargées.

Une différence importante entre les archives dynamiques et statiques est qu'elles constituent toujours un «module complémentaire» sur les archives statiques de base, qui peuvent être soit des archives intégrées dans le kit de distribution Java, soit créées séparément de manière classique en 3 étapes.

Syntaxiquement, l'utilisation des archives Dynamic CDS se résume à deux lancements JVM avec deux options:

1. Essai avec l'option -XX:ArchiveClassesAtExit=archive.jsa , à la fin de laquelle une archive dynamique sera créée (vous pouvez spécifier n'importe quel chemin et nom)
2. Lancement utile avec l'option -XX:SharedArchiveFile=archive.jsa , qui utilisera l'archive précédemment créée

La deuxième option n'est pas différente de la connexion d'une archive statique régulière. Mais si tout à coup l'archive statique de base n'est pas à l'emplacement par défaut (à l'intérieur du JDK), cette option peut également inclure une indication du chemin d'accès, par exemple:

 -XX:SharedArchiveFile=base.jsa:dynamic.jsa 

(sous Windows, le séparateur de chemin doit être le caractère ";")

Vous en savez maintenant assez sur AppCDS pour pouvoir le regarder en action.

Pratique

Lapin expérimental

Pour que notre application d'AppCDS dans la pratique ne se limite pas à un HelloWorld typique, nous prendrons comme base la vraie application sur Spring Boot. Mes collègues et moi devons souvent regarder les journaux des applications sur des serveurs de test distants et regarder en direct, tout comme ils sont écrits. Utiliser pour cela un agrégateur de journaux à part entière (comme ELK) n'est souvent pas approprié; télécharger des fichiers journaux à l'infini - pendant longtemps, et regarder la sortie de la console grise de tail est déprimant. Par conséquent, j'ai créé une application Web qui peut sortir tous les journaux en temps réel directement vers le navigateur, coloriser les lignes par niveau d'importance (en formatant XML en même temps), agréger plusieurs journaux en un seul, ainsi que d'autres astuces. Il s'appelle ANALOG (comme un «analyseur de journaux», bien que ce ne soit pas vrai) et se trouve sur GitHub . Cliquez sur la capture d'écran pour agrandir:

Techniquement, il s'agit d'une application sur Spring Boot + Spring Integration, sous le capot de laquelle tail , docker et kubectl (pour prendre en charge les journaux de fichiers, les conteneurs Docker et les ressources Kubernetes, respectivement). Il se présente sous la forme du fichier JAR Spring Boot «épais» classique. Au moment de l'exécution, classes10K classes sont suspendues dans la mémoire de l'application, dont la grande majorité sont des classes Spring et JDK. Évidemment, ces classes changent assez rarement, ce qui signifie qu'elles peuvent être placées dans une archive partagée et réutilisées dans toutes les instances de l'application, économisant de la mémoire et du CPU.

Expérience unique

Appliquons maintenant les connaissances existantes de Dynamic AppCDS au lapin expérimental. Puisque tout est connu en comparaison, nous aurons besoin d'un point de référence - l'état du programme avec lequel nous comparerons les résultats obtenus pendant l'expérience.

Remarques introductives

• Toutes les autres commandes sont pour Linux. Les différences pour Windows et macOS ne sont pas fondamentales.
• La compilation JIT peut sensiblement affecter les résultats et, en théorie, pour la pureté de l'expérience, elle pourrait être désactivée (avec l'option -Xint , comme cela a été fait dans l' article mentionné), mais dans un souci de plausibilité maximale, il a été décidé de ne pas le faire.
• Les nombres suivants concernant l'heure de début ont été obtenus sur un serveur de test rapide. Sur les machines qui fonctionnent, des nombres similaires sont généralement plus modestes, mais comme nous ne nous intéressons pas aux valeurs absolues, mais aux incréments de pourcentage, nous considérons cette différence comme insignifiante.
• Afin de ne pas entrer prématurément dans la complexité de la mesure de la mémoire partagée, pour l'instant nous omettons d'obtenir des lectures précises en octets. Au lieu de cela, nous introduisons le concept de « potentiel CDS », exprimé en pourcentage du nombre de classes partagées par rapport au nombre total de classes chargées. Il s'agit bien sûr d'une quantité abstraite, mais d'un autre côté, elle affecte directement la consommation réelle de mémoire; de plus, sa définition ne dépend pas du tout de l'OS, et pour son calcul, seuls les logs sont suffisants.

Point de référence

Soit ce point l'état d'une application fraîchement téléchargée, c'est-à-dire sans utilisation explicite d'aucun AppCDS'ov et autres. Pour l'évaluer, nous avons besoin de:

1. Installez OpenJDK 13 (par exemple, la distribution Liberica domestique, mais pas la version lite).
   Il doit également être ajouté à la variable d'environnement PATH ou à JAVA_HOME , par exemple, comme ceci:

   
   

    export JAVA_HOME=~/tools/jdk-13 

   
   

2. Téléchargez ANALOG (au moment de la rédaction, la dernière version était la v0.12.1).

   
   

   Si nécessaire, vous pouvez spécifier dans le fichier config/application.yaml du paramètre server.address le nom d'hôte externe pour accéder à l'application (par défaut, localhost est spécifié).

   
   

3. Activez la journalisation du chargement de classe JVM.
   Pour ce faire, vous pouvez JAVA_OPTS la variable d'environnement JAVA_OPTS avec cette valeur:

   
   

    export JAVA_OPTS=-Xlog:class+load=info:file=log/class-load.log 

   
   

   Cette option sera transmise à la JVM et lui demandera de garantir la source de chaque classe.

   
   

4. Exécutez un test:

   
   
   1. Exécutez l'application avec le script bin/analog
   2. Ouvrez http: // localhost: 8083 dans le navigateur, piquez les boutons et les daws
   3. Arrêtez l'application en appuyant sur Ctrl+C dans la console de script bin/analog
   
   

5. Prendre le résultat (à partir des fichiers du log/ répertoire)

   
   

   • Nombre total de classes chargées (par class-load.log ):

     
     

      cat class-load.log | wc -l 10463 

     
     

   • Combien d'entre eux sont téléchargés à partir d'une archive partagée (selon elle):

     
     

      grep -o 'source: shared' - class-load.log 1146 

     
     

   • Heure de début moyenne (après une série de démarrages; par analog.log ):

     
     

      grep -oE '\(JVM running for .+\)' analog.log | grep -oE '[0-9]\.[0-9]+' | awk '{ total += $1; count++ } END { print total/count }' 4.5225 

     
     
   
   

Ainsi, à cette étape, le potentiel du CDS était de 1146/10463=0,1095 -11% . Si vous êtes surpris de l'origine des classes partagées (après tout, nous n'avons pas encore inclus d'AppCDS), je vous rappelle qu'à partir de la 12ème version, le JDK inclut l' archive CDS finie $JAVA_HOME/lib/server/classes.jsa , construite par pas moins de liste de classes prête:

 cat $JAVA_HOME/lib/classlist | wc -l 1170 

Maintenant, après avoir évalué l'état initial de l'application, nous pouvons lui appliquer AppCDS et, par comparaison, comprendre ce que cela donne.

Expérience de base

Comme la documentation nous a été léguée, pour créer une archive AppCDS dynamique, vous devez effectuer un seul essai de l'application avec l'option -XX:ArchiveClassesAtExit . Dès le prochain lancement, l'archive peut être utilisée et recevoir des bénéfices. Pour vérifier cela sur le même lapin expérimental (AnaLog), vous avez besoin de:

1. Ajoutez l'option spécifiée à la commande d'exécution:

   
   

    export JAVA_OPTS="$JAVA_OPTS -XX:ArchiveClassesAtExit=work/classes.jsa" 

   
   

2. Étendre la journalisation:

   
   

    export JAVA_OPTS="$JAVA_OPTS -Xlog:cds=debug:file=log/cds.log" 

   
   

   Cette option forcera le processus de construction d'une archive CDS à être enregistré lorsque l'application sera arrêtée.

   
   

3. Effectuez le même test que pour le point de référence:

   
   
   1. Exécutez l'application avec le script bin/analog
   2. Ouvrez http: // localhost: 8083 dans le navigateur, piquez les boutons et les daws
   3. Arrêtez l'application en appuyant sur Ctrl+C dans la console de script bin/analog
      Après cela, un énorme footcloth avec toutes sortes d'avertissements devrait tomber dans la console, et le log/cds.log devrait être rempli de détails; ils ne nous intéressent pas encore.
   
   

4. Faites passer le mode de lancement d'essai à utile:

   
   

    export JAVA_OPTS="-XX:SharedArchiveFile=work/classes.jsa -Xlog:class+load=info:file=log/class-load.log -Xlog:class+path=debug:file=log/class-path.log" 

   
   

   Ici, nous ne JAVA_OPTS pas la variable JAVA_OPTS , mais nous la JAVA_OPTS par de nouvelles valeurs qui incluent (1) l'utilisation d'une archive partagée, (2) la journalisation des sources de classe et (3) la journalisation des vérifications de chemin de classe.

   
   

5. Effectuez un lancement utile de l'application selon le schéma du paragraphe 3.

   
   

6. Prendre le résultat (à partir des fichiers du log/ répertoire)

   
   

   • Vérification de l'application réelle d'AppCDS (par le class-path.log ):

     
     

      [0.011s][info][class,path] type=BOOT [0.011s][info][class,path] Expecting BOOT path=/home/upc/tools/jdk-13/lib/modules [0.011s][info][class,path] ok [0.011s][info][class,path] type=APP [0.011s][info][class,path] Expecting -Djava.class.path=/home/upc/tmp/analog/lib/analog.jar [0.011s][info][class,path] ok 

     
     

     Les marques ok après les lignes type=BOOT et type=APP indiquent respectivement l'ouverture, la vérification et le chargement réussis des archives CDS intégrées et appliquées.

     
     

   • Nombre total de classes chargées (par class-load.log ):

     
     

      cat class-load.log | wc -l 10403 

     
     

   • Combien d'entre eux sont téléchargés à partir d'une archive partagée (selon elle):

     
     

      grep -o 'source: shared' -c class-load.log 6910 

     
     

   • Heure de début moyenne (après une série de démarrages; par fichier analog.log ):

     
     

      grep -oE '\(JVM running for .+\)' analog.log | grep -oE '[0-9]\.[0-9]+' | awk '{ total += $1; count++ } END { print total/count }' 4.04167 

     
     
   
   

Mais à ce 6910/10403≈0,66 , le potentiel du CDS était déjà de 6910/10403≈0,66 = 66% , c'est-à-dire qu'il a augmenté de 55% par rapport au point de référence. Dans le même temps, le temps de lancement moyen a été réduit de (4,5225-4,04167)=0,48 seconde, soit le démarrage est plus rapide de ≈10,6% de la valeur initiale.

Analyse des résultats

Le titre de travail de l'article est: "Pourquoi si peu?"

Nous, comme, avons tout fait selon les instructions, mais toutes les classes n'étaient pas dans l'archive. Leur nombre affecte le temps de lancement non moins que la puissance de calcul de la machine de l'expérimentateur, nous allons donc nous concentrer sur ce nombre.

Si vous vous en souvenez, nous avons ignoré le fichier log/cds.log créé lors de l'arrêt de l'application expérimentale après la période d'essai. Dans ce fichier HotSpot, la JVM a gentiment noté les classes d'avertissement pour chaque classe qui n'apparaissait pas dans l'archive CDS. Voici le nombre total de ces marques:

 grep -o '[warning]' cds.log -c 3591 

Étant donné que seules 10 000 classes et plus sont mentionnées dans le journal class-load.log et que 66% d'entre elles sont téléchargées à partir de l'archive, il n'est pas difficile de comprendre que les 3600 classes répertoriées dans cds.log représentent les 44% «manquants» du potentiel CDS. Vous devez maintenant découvrir pourquoi ils ont été ignorés.

Si vous regardez le journal cds.log, il s'avère qu'il n'y a que 4 raisons uniques pour sauter des classes. Voici des exemples de chacun d'eux:

 Skipping org/springframework/web/client/HttpClientErrorException: Not linked Pre JDK 6 class not supported by CDS: 49.0 org/jrobin/core/RrdUpdater Skipping java/util/stream/Collectors$$Lambda$554: Unsafe anonymous class Skipping ch/qos/logback/classic/LoggerContext: interface org/slf4j/ILoggerFactory is excluded 

Parmi les 3591 classes manquées, ces raisons se retrouvent ici avec une telle fréquence:

Examinez-les de plus près:

• Unsafe anonymous class
  JVM “” , -, .

  
  

• Not linked
  , “” , , . , StackOverflow . , , “” () JAR- , AppCDS. , ( ).

  
  

• Pre JDK 6 class
  , CDS Java 5. class- , CDS . , , 6, Java, . - , runtime- (, slf4j).

  
  

• Skipping ... : super class/interface ... is excluded
  , “” . CDS', . Par exemple:

  
  

   [warning][cds] Pre JDK 6 class not supported by CDS: 49.0 org/slf4j/spi/MDCAdapter [warning][cds] Skipping ch/qos/logback/classic/util/LogbackMDCAdapter: interface org/slf4j/spi/MDCAdapter is excluded 

  
  

Conclusion

CDS 100%.

, , , , , . .

JEP-310 , AppCDS JDK. . , . CDS (, , ) .

 export ANALOG_OPTS="-Djavamelody.enabled=false -Dlogging.config=classpath:logging/logback-console.xml" export ANALOG_OPTS="$ANALOG_OPTS -Dnodes.this.agentPort=7801 -Dserver.port=8091" 

 export JAVA_OPTS="-Xlog:class+load=info:file=log/class-load-%p.log -Xlog:class+path=debug:file=log/class-path-%p.log" export JAVA_OPTS="$JAVA_OPTS -XX:SharedArchiveFile=work/classes.jsa" 

, . . :

1. server.port nodes.this.agentPort , :

   
   

    export ANALOG_OPTS="$ANALOG_OPTS -Dnodes.this.agentPort=7801 -Dserver.port=8091" 

   
   

   , ( ).

   
   

2. bin/analog

   
   

   () http://localhost:8091 ,

   
   

3. PID ( ), :

   
   

    pgrep -f analog 13792 

   
   

4. pmap ( ):

   
   

    pmap -XX 13792 | sed -n -e '2p;$p' Address Perm Offset Device Inode Size KernelPageSize MMUPageSize Rss Pss Shared_Clean Shared_Dirty Private_Clean Private_Dirty Referenced Anonymous LazyFree AnonHugePages ShmemPmdMapped Shared_Hugetlb Private_Hugetlb Swap SwapPss Locked ProtectionKey VmFlagsMapping 3186952 1548 1548 328132 325183 3256 0 10848 314028 212620 314024 0 0 0 0 0 0 0 325183 0 KB 

   
   

   ; .

   
   

5. 1-4 (, ).

   
   

pmap . CDS' . , , PSS:

The "proportional set size" (PSS) of a process is the count of pages it has in memory, where each page is divided by the number of processes sharing it. So if a process has 1000 pages all to itself, and 1000 shared with one other process, its PSS will be 1500.

, , “ ” . , .

PSS , :

, - :

• “”
• , PSS
• “” , PSS

, . AppCDS. , -XX:SharedArchiveFile=work/classes.jsa -Xshare:off , CDS . , .

:

• PSS AppCDS CDS.
  . , , HelloWorld- JVM CDS 2 , CDS. PSS CDS, . :

  
  

• PSS AppCDS 2- ; 3- .
  , , , . , AppCDS, , , 3- .
  : , CDS? :

  
  

• CDS/AppCDS JVM , PSS . , , pmap , “” sed '. :

  
  

   pmap -X `pgrep -f analog` 14981: # ... Address Perm Offset Device Inode Size Rss Pss ... Mapping # ... ... 7faf5e31a000 r-xp 00000000 08:03 269427 17944 14200 14200 ... libjvm.so # ... ... 7faf5f7f9000 r-xp 00000000 08:03 1447189 1948 1756 25 ... libc-2.27.so 

  
  

  ( Mapping ) , “” . JVM ( libjvm.so ), ( libc-2.27.so ). :

  
  

  For the Java VM, the read-only parts of the loaded shared libraries (ie libjvm.so ) can be shared between all the VM instances running at the same time. This explains why, taking together, the two VM's consume less memory (ie have a smaller memory footprint) than the simple sum of their single resident set sizes when running alone.

  
  

. , , . , , JVM , Java- . GeekOut:

, , , AppCDS , .. Java-. , JVM, , - .

VisualVM Metaspace AppCDS , :

AppCDS

AppCDS

, 128 Metaspace AppCDS 64.2 MiB / 8.96 MiB ≈7,2 , CDS . (. ) 66.4 MiB / 13.9 MiB ≈4,8 . , AppCDS , Metaspace. Metaspace, , CDS .

Au lieu d'une conclusion

Spring Boot AppCDS – JVM, .

• JEP-350 Dynamic CDS Archives – JDK 13.
• Spring Boot ó CDS ( ). , 100% - 66% . , ≈11% ( 15%, ).
• , 5- PSS ( ). , AppCDS , , 8% (PSS). , CDS, , . AppCDS .
• Metaspace, , AppCDS 5 , CDS.

, , AppCDS, , “killer feature”. Spring Boot. , , AppCDS . , , AppCDS Spring Boot. , …

by Nick Fewings on Unsplash