Surveiller et maintenir votre instance AEM monitoring-and-maintaining-your-aem-instance

Une fois les instances AEM déployées, certaines tâches sont nécessaires pour surveiller et conserver leur fonctionnalité, leur performance et leur intégrité.

Un facteur clé est que, pour identifier les problèmes potentiels, vous devez connaître l’apparence et le comportement de vos systèmes dans des conditions normales. Pour ce faire, il est préférable de surveiller le système et de collecter des informations sur une période donnée.

Sauvegardes backups

Il est recommandé de sauvegarder les éléments suivants :

Votre entreprise aura probablement une stratégie de sauvegarde que vous devrez suivre, des considérations supplémentaires sur les éléments à sauvegarder et quand inclure :

Souvent, une sauvegarde complète est effectuée à intervalles réguliers (par exemple tous les jours, toutes les semaines ou tous les mois), avec des sauvegardes incrémentielles entre les deux (par exemple toutes les heures, tous les jours ou toutes les semaines).

Sauvegarde de votre installation logicielle backing-up-your-software-installation

Après l’installation ou des modifications importantes de la configuration, effectuez une sauvegarde de votre installation logicielle.

Pour ce faire, vous devez sauvegarde de votre référentiel entier ; puis :

Sauvegarde du référentiel backing-up-your-repository

Le Sauvegarde et restauration la section de la documentation CRX couvre tous les problèmes liés aux sauvegardes du référentiel CRX.

Pour plus d’informations sur la réalisation d’une sauvegarde "à chaud" en ligne, voir Création d’une sauvegarde en ligne.

Purge de version version-purging

Le Purge des versions est destiné à purger les versions d’un noeud ou d’une hiérarchie de noeuds dans votre référentiel. Son Principal objectif est de vous aider à réduire la taille de votre référentiel en supprimant les anciennes versions de vos noeuds.

Cette section traite des opérations de maintenance liées à la fonctionnalité de création de versions d’AEM. Le Purge de la version est destiné à purger les versions d’un noeud ou d’une hiérarchie de noeuds dans votre référentiel. Son Principal objectif est de vous aider à réduire la taille de votre référentiel en supprimant les anciennes versions de vos noeuds.

Présentation overview

L’outil Purge de versions est disponible dans la console Outils sous Versions ou directement à l’adresse :

https://<server>:<port>/etc/versioning/purge.html

Chemin de début Un chemin absolu sur lequel la purge doit être effectuée. Vous pouvez sélectionner le chemin de début en cliquant sur le navigateur d’arborescence du référentiel.

Récursif Lors de la purge des données, vous pouvez choisir d’effectuer une opération sur un nœud ou sur une hiérarchie complète en choisissant Récursif. Dans ce cas, le chemin donné définit le nœud racine de la hiérarchie.

Versions maximales à conserver Nombre maximal de versions à conserver pour un nœud. Lorsque ce nombre dépasse la valeur, les versions les plus anciennes sont purgées.

Âge de version maximal L’âge maximal de la version d’un nœud. Lorsque l’âge d’une version dépasse cette valeur, elle est purgée.

Exécution d’essai Étant donné que la suppression des versions de contenu est définitive et ne peut pas être rétablie sans la restauration d’une sauvegarde, l’outil Purge de versions fournit un mode Exécution d’essai qui permet d’afficher un aperçu des versions purgées. Pour lancer le mode Exécution d’essai du processus de purge, cliquez sur Exécution d’essai.

Purge Lancez la purge des versions sur le nœud défini par le chemin de début.

Purge des versions d’un site web purging-versions-of-a-web-site

Pour purger les versions d’un site web, procédez comme suit :

Analyse de la console analyzing-the-console

Le Exécution d’essai et Purge Les processus répertorient tous les noeuds qui ont été traités. Au cours du processus, un nœud peut avoir l’un des statuts suivants :

Par ailleurs, la console affiche des informations utiles sur les versions :

Dans l’exemple suivant :

Utilisation des enregistrements d’audit et des fichiers journaux working-with-audit-records-and-log-files

Les enregistrements de contrôle et les fichiers journaux relatifs à Adobe Experience Manager (AEM) se trouvent à différents emplacements. Vous trouverez ci-dessous un aperçu de ce que vous pouvez trouver.

Utiliser des journaux working-with-logs

AEM WCM enregistre des journaux détaillés. Une fois que vous avez décompressé et démarré Quickstart, vous pouvez trouver les journaux dans :

Rotation des fichiers journaux log-file-rotation

La rotation de fichier journal fait référence au processus qui limite la croissance du fichier par la création régulière d’un nouveau fichier. Dans AEM, un fichier journal appelé error.log est activé une fois par jour, selon les règles en place :

Recherche des fichiers journaux finding-the-log-files

Divers fichiers journaux sont conservés sur le serveur de fichiers sur lequel vous avez installé AEM :

Activation du niveau de journalisation DÉBOGUER activating-the-debug-log-level

Le niveau de journalisation par défaut Configuration de la journalisation Apache Sling est Informations. Par conséquent, les messages de débogage ne sont pas consignés.

Pour activer le niveau de journalisation de débogage pour un journal, définissez la propriété org.apache.sling.commons.log.level pour le débogage dans le référentiel. Par exemple, sur /libs/sling/config/org.apache.sling.commons.log.LogManager pour configurer la journalisation globale Apache Sling.

Une ligne du fichier de débogage commence généralement par DEBUG, puis fournit le niveau de journalisation, l’action d’installation et le message du journal. Par exemple :

DEBUG 3 WebApp Panel: WebApp successfully deployed

Les niveaux de journal sont les suivants :

Création d’un fichier journal personnalisé create-a-custom-log-file

Dans certains cas, vous pouvez créer un fichier journal personnalisé avec un niveau de journalisation différent. Vous pouvez le faire depuis le référentiel en procédant comme suit :

La console Felix fournit également des informations sur la prise en charge du journal Sling à l’adresse ../system/console/slinglog ; par exemple, http://localhost:4502/system/console/slinglog.

Recherche des enregistrements d’audit finding-the-audit-records

Les registres d’audit sont tenus pour indiquer qui a fait quoi et quand. Différents enregistrements d’audit sont générés pour les événements WCM et OSGi AEM.

AEM les enregistrements d’audit WCM affichés lors de la création de pages aem-wcm-audit-records-shown-when-page-authoring

AEM des enregistrements d’audit WCM dans le référentiel aem-wcm-auditing-records-within-the-repository

Dans le dossier /var/audit, les enregistrements d’audit sont conservés selon la ressource. Vous pouvez descendre jusqu’à afficher les enregistrements individuels et les informations qu’ils contiennent.

Ces entrées contiennent les mêmes informations que celles affichées lors de la modification d’une page.

Enregistrements d’audit OSGi à partir de la console web osgi-audit-records-from-the-web-console

Les événements OSGi produisent également des enregistrements d’audit pouvant être affichés dans l’onglet Statut de la configuration -> Onglet Fichiers journaux dans la console web Adobe AEM :

Surveillance de vos agents de réplication monitoring-your-replication-agents

Vous pouvez surveiller vos files d’attente de réplication pour détecter lorsqu’une file d’attente est arrêtée ou bloquée, ce qui peut à son tour indiquer un problème avec une instance de publication ou un système externe :

Pour surveiller un agent de réplication :

Vous pouvez toujours développer une solution pour détecter tous les agents de réplication (situés sous /etc/replication/author ou /etc/replication/publish), puis vérifier le statut de l’agent (enabled, disabled) et de la file d’attente sous-jacente (active, idle, blocked).

Surveillance des performances monitoring-performance

Optimisation des performances est un processus interactif qui reçoit l’attention pendant le développement. Après le déploiement, il est généralement examiné après des intervalles ou des événements spécifiques.

Les méthodes utilisées lors de la collecte des informations pour le ciblage peuvent également être utilisées pour une surveillance continue.

Vous trouverez ci-après une liste des problèmes de performance qui surviennent de temps à autre, ainsi que des solutions potentielles sur la façon de les repérer et de les résoudre.

Les problèmes de performances peuvent être dus à un certain nombre de causes qui n’ont rien à voir avec votre site web, notamment des ralentissements temporaires de la vitesse de connexion, de la charge du processeur, etc.

Cela peut également avoir un impact sur tous vos visiteurs, ou seulement sur un sous-ensemble d’entre eux.

Toutes ces informations doivent être obtenues, classées et analysées avant de pouvoir optimiser la performance générale ou résoudre des problèmes spécifiques.

Outils de surveillance et d’analyse des performances tools-for-monitoring-and-analyzing-performance

Vous trouverez ci-dessous un bref aperçu de certains outils disponibles pour surveiller et analyser les performances.

Certaines dépendent de votre système d’exploitation.

Interprétation de request.log interpreting-the-request-log

Ce fichier permet d’enregistrer des données de base sur chaque demande envoyée à AEM. Vous pouvez en tirer des conclusions précieuses.

request.log fournit une méthode intégrée pour identifier la durée des demandes. Pour le développement, il est utile d’utiliser tail -f sur request.log et d’observer les temps de réponse lents. Pour analyser un fichier request.log de plus grande envergure, nous vous recommandons l’utilisation de rlog.jar, qui permet de trier et de filtrer les délais de réponse.

Nous vous recommandons d’isoler les pages « lentes » de request.log, puis de les régler individuellement pour une meilleure performance. Cette opération est généralement effectuée en incorporant des mesures de performance par composant, ou en utilisant un outil de profilage des performances tel que [yourkit](https://www.yourkit.com/).

Surveillance du trafic sur votre site web monitoring-traffic-on-your-website

Le journal des requêtes enregistre chaque requête effectuée, ainsi que la réponse apportée :

09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

En totalisant toutes les entrées de GET au cours de périodes spécifiques (par exemple, sur différentes périodes de 24 heures), vous pouvez effectuer des instructions sur le trafic moyen de votre site web.

Surveillance des temps de réponse avec request.log monitoring-response-times-with-the-request-log

Le journal des demande est un point de départ intéressant pour l’analyse de performances :

<cq-installation-dir>/crx-quickstart/logs/request.log

Le journal se présente comme suit (les lignes sont raccourcies par souci de simplicité) :

31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

Ce journal comporte une ligne par requête ou réponse :

En utilisant de petits scripts, vous pouvez extraire les informations requises du fichier journal et assembler les statistiques de votre choix. Vous pouvez ainsi identifier les pages ou les types de pages lents et déterminer si les performances globales sont satisfaisantes.

Surveillance des temps de réponse de la recherche avec request.log monitoring-search-response-times-with-the-request-log

Les demandes de recherche sont également enregistrées dans le fichier journal :

31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

Ainsi, comme ci-dessus, vous pouvez utiliser des scripts pour extraire les informations pertinentes et créer des statistiques.

Cependant, une fois que vous avez déterminé le temps de réponse, vous devrez peut-être analyser pourquoi la requête prend le temps qu’elle prend et ce qui peut être fait pour améliorer la réponse.

Surveillance du nombre et de l’impact des utilisateurs simultanés monitoring-the-number-and-impact-of-concurrent-users

request.log peut encore être utilisé pour surveiller les accès simultanés et la réaction du système dans cette situation.

Des tests doivent être effectués pour déterminer le nombre d’utilisateurs simultanés que le système peut traiter avant qu’un impact négatif ne soit observé. Là encore, des scripts peuvent être utilisés pour extraire les résultats du fichier journal :

31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

Utilisation de rlog.jar pour rechercher des requêtes avec des durées longues using-rlog-jar-to-find-requests-with-long-duration-times

AEM comprend divers outils d’assistance situés dans :

<cq-installation-dir>/crx-quickstart/opt/helpers

L’un de ces outils, rlog.jar, peut être utilisé pour trier rapidement request.log de sorte que les demandes soient affichées selon la durée, c’est-à-dire de la plus longue à la plus courte.

La commande suivante affiche les arguments possibles :

$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
  java -jar rlog.jar [options] <filename>
Options:
  -h               Prints this usage.
  -n <maxResults>  Limits output to <maxResults> lines.
  -m <maxRequests> Limits input to <maxRequest> requests.
  -xdev            Exclude POST request to CRXDE.

Par exemple, vous pouvez l’exécuter en spécifiant le fichier request.log en tant que paramètre et afficher les 10 premières demandes ayant la plus longue durée :

$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8

Vous pouvez avoir à concaténer les différents fichiers request.log si vous devez effectuer cette opération sur un grand échantillon de données.

Apache Bench apache-bench

Pour minimiser l’impact des cas particuliers (tels que le nettoyage, etc.), il est recommandé d’utiliser un outil tel que apachebench (voir par exemple ab pour obtenir plus d’informations) pour vous aider à identifier les fuites de mémoire et à analyser de manière sélective le délai de réponse.

Apache Bench peut être utilisé de la manière suivante :

$ ab -c 5 -k -n 1000 "http://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

Les chiffres ci-dessus sont extraits d’un ordinateur portable standard MacBook Pro (mi-2010) avec accès à la page d’entreprise geometrixx, comme inclus dans une installation d’AEM par défaut. Cette page est très simple mais n’est pas optimisée en terme de performance.

apachebench affiche également la durée par demande comme la moyenne de toutes les requêtes simultanées ; ici Time per request: 54.595 [ms] (moyenne de toutes les requêtes simultanées). Vous pouvez modifier la valeur du paramètre d’accès simultané -c (nombre de demandes multiples à exécuter à un moment donné) pour voir si cela produit un effet.

Compteurs de requêtes request-counters

Les informations sur le trafic de requêtes (nombre de requêtes pendant une période spécifique) vous donnent une indication de la charge sur votre instance. Ces informations peuvent être extraites de request.log à l’aide des compteurs, automatisant ainsi la collecte de données pour vous permettre de constater :

Pour automatiser la collecte des informations, vous pouvez également installer un RequestFilter afin d’incrémenter un compteur pour chaque requête. Plusieurs compteurs peuvent être utilisés pour différentes périodes.

Les informations collectées peuvent être utilisées pour indiquer :

Commentaires HTML html-comments

Nous vous recommandons d’inclure des html comments sur la performance du serveur pour chaque projet. De nombreux bons exemples publics peuvent être trouvés; sélectionnez une page, ouvrez la source de la page pour l’afficher et faites défiler la page vers le bas, le code suivant peut être affiché :

</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

Surveillance des performances à l’aide de JConsole monitoring-performance-using-jconsole

La commande d’outil jconsole est disponible avec JDK.

Surveillance de la performance à l’aide de (J)VisualVM monitoring-performance-using-j-visualvm

Depuis le JDK 1.6, la commande d’outil jvisualvm est disponible. Une fois que vous avez installé le JDK 1.6. vous pouvez :

Vous pouvez utiliser cet outil pour générer des vidages de thread et des vidages de mémoire. Ces informations sont souvent demandées par l’équipe d’assistance technique.

Collecte des informations information-collection

Connaître autant que possible votre installation peut vous aider à déterminer ce qui a pu provoquer un changement de performances et si ces modifications sont justifiées. Ces informations doivent être collectées de façon régulière, afin que vous puissiez facilement identifier des changements importants.

Les informations suivantes peuvent s’avérer utiles :

Combien d’auteur(e)s travaillent avec le système ? how-many-authors-are-working-with-the-system

Pour afficher le nombre d’auteurs qui ont utilisé le système depuis l’installation, utilisez la ligne de commande :

cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

Pour afficher le nombre d’auteurs travaillant sur une date donnée :

grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

Quel est le nombre moyen d’activations de page par jour ? what-is-the-average-number-of-page-activations-per-day

Pour afficher le nombre total d’activations de page depuis l’installation du serveur, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

Calculez ensuite le nombre de jours écoulés depuis l’installation pour calculer la moyenne.

Combien de pages maintenez-vous actuellement sur ce système ? how-many-pages-do-you-currently-maintain-on-this-system

Pour voir le nombre de pages actuellement sur le serveur, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

Si vous utilisez MSM, quel est le nombre moyen de déploiements par mois ? if-you-use-msm-what-is-the-average-number-of-rollouts-per-month

Pour déterminer le nombre total de déploiements depuis l’installation, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

Calculez le nombre de mois écoulés depuis l’installation pour calculer la moyenne.

Quel est le nombre moyen de Live Copies par mois ? what-is-the-average-number-of-live-copies-per-month

Pour déterminer le nombre total de Live Copies effectuées depuis l’installation, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

Utilisez toujours le nombre de mois écoulés depuis l’installation pour calculer la moyenne.

Si vous utilisez AEM Assets, combien de ressources maintenez-vous actuellement ? if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets

Pour voir le nombre de ressource de gestion des ressources numériques que vous conservez actuellement, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

Quelle est la taille moyenne des ressources ? what-is-the-average-size-of-the-assets

Pour déterminer la taille totale du dossier /var/dam :

Combien de modèles sont actuellement utilisés ? how-many-templates-are-currently-used

Pour voir le nombre de modèles actuellement sur le serveur, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

Combien de composants sont actuellement utilisés ? how-many-components-are-currently-used

Pour voir le nombre de composants actuellement sur le serveur, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

Combien de demandes par heure recevez-vous sur le système de création lorsque le niveau d’activité est élevé ? how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time

Pour déterminer le nombre de demandes par heure que vous recevez sur le système de création lorsque le niveau d’activité est élevé :

Combien de demandes par heure recevez-vous sur le système de publication lorsque le niveau d’activité est élevé ? how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time

Répétez la procédure ci-dessus sur votre instance de publication.

Analyse de scénarios spécifiques analyzing-specific-scenarios

Voici une liste de suggestions des éléments à vérifier si vous commencez à rencontrer certains problèmes de performance. La liste n’est (malheureusement) pas tout à fait complète.

Processeur à 100 % cpu-at

Si le processeur de votre système fonctionne constamment à 100 %, voir :

Mémoire insuffisante out-of-memory

Bien que de telles erreurs doivent être détectées pendant le développement et les tests, certains scénarios peuvent passer.

Si votre système manque de mémoire, cela peut être observé de différentes manières, notamment par la dégradation des performances et les messages d’erreur, y compris le sous-texte :

java.lang.OutOfMemoryError

Dans ce cas, vérifiez les éléments suivants :

E/S de disque disk-i-o

Si votre système manque d’espace disque ou si vous constatez que le disque est en train de se réduire, procédez comme suit :

Dégradation régulière des performances regular-performance-degradation

Si les performances de votre instance se détériorent après chaque redémarrage (parfois une semaine ou plus tard), les éléments suivants peuvent être vérifiés :

Réglage JVM jvm-tuning

La machine virtuelle Java (JVM) a été considérablement améliorée en termes de réglage (notamment depuis Java 7). Pour cette raison, la spécification d’une taille JVM fixe raisonnable et l’utilisation des valeurs par défaut sont souvent appropriées.

Si les paramètres par défaut ne conviennent pas, il est important d’établir une méthode pour surveiller et évaluer les performances du GC avant de tenter d’ajuster la JVM. cela peut impliquer des facteurs de surveillance, notamment la taille du tas, l’algorithme et d’autres aspects.

Voici quelques choix courants :

Le rapport résultant peut être assimilé par un visualiseur GC comme :

[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)

Ou JConsole :

Cela vous aidera à déterminer la quantité de mémoire utilisée, les algorithmes GC utilisés, leur durée d’exécution et l’impact sur la performance de l’application. Sans cela, le réglage consiste simplement à manipuler des boutons de façon aléatoire.