Objectif

Cet article aborde les problèmes critiques et courants liés à AEM et la façon de les analyser.

Problèmes de performances des sites AEM

Symptômes d’un problème de performances

  1. Chargement des pages lent  
  2. Création ou modification des pages lentes
  3. Temps de réponse d’AEM lents
  4. Absence de réponse d’AEM pour certaines requêtes
  5. Journal de requête d’AEM indiquant des temps de réponse lents

Causes des problèmes de performances

  1. Conflit de threads - requêtes d’exécution longues comme des recherches lentes, tâche d’écriture lourde en arrière-plan, déplacement de branches complètes de contenu du site, etc.
  2. Utilisation intensive du processeur
  3. Requêtes volumineuses comme des recherches volumineuses ou un code d’application/des composants inefficaces, etc.
  4. Insuffisance de maintenance
  5. Insuffisance de capacité de mise en cache du répartiteur
  6. Insuffisance de CDN
  7. Insuffisance de capacité de mise en cache du navigateur
  8. Excès de scripts chargés sur la page et en haut de la page
  9. Chargement de la CSS via la page et non depuis l’en-tête HTML
  10. Insuffisance de la taille du serveur ou mauvaise architecture
  11. Problèmes de mémoire (voir ci-dessous)

Méthode d’analyse des problèmes de performances

1. Capturez une série d’images mémoire de threads et analysez-la.

2. Vérifiez au niveau de l’OS si le processus java d’AEM engendre une utilisation intensive du processeur.

    Linux : utilisez la commande top pour vérifier l’utilisation du processeur.

    Windows : utilisez le gestionnaire des tâches Windows.

    Si AEM engendre une utilisation intensive du processeur, exécutez l’outil de profilage prêt à l’emploi pendant quelques minutes, puis analysez le résultat.

3. Analysez le fichier request.log à la recherche de requêtes lentes.

4. Examinez les procédures de maintenance de votre système et assurez-vous d’effectuer correctement la maintenance sur AEM, y compris les tâches suivantes :

  • Nettoyage de révision (MongoMK et Database DocumentNodeStore uniquement) - au moins tous les jours
  • Compression des fichiers tar hors ligne (TarMK uniquement) - deux fois par semaine
  • Nettoyage de la mémoire d’entrepôt de données (systèmes équipés de FileDataStore ou de DataStore S3 uniquement) - toutes les semaines
  • Purge des flux de travail - toutes les semaines
  • Purge des versions - toutes les semaines
  • Purge de AuditLog - toutes les semaines

Pour plus de détails sur la maintenance d’AEM, consultez cet article.

5. Examinez les stratégies de mise en cache implémentées au niveau du répartiteur d’AEM.  Pour commencer, cherchez à déterminer quand et comment le répartiteur met les fichiers en cache et invalide les fichiers mis en cache.

6. Revoyez la mise en cache de votre site.

7. Utilisez les outils d’analyse du site utilisés côté client, comme la fonctionnalité Audits dans le volet Outils de développement du navigateur Google Chrome.  Ces outils fournissent des recommandations d’amélioration des performances côté client.

Solutions aux problèmes de performances courants

Problèmes de performances des AEM Assets

Symptômes d’un problème de performances des ressources

  • Téléchargement lent des fichiers vers les IU /assets.html ou /damadmin
  • Génération de l’affichage des miniatures excessivement long
  • Opérations des ressources telles que le déplacement, la suppression, la modification ou la mise à jour des métadonnées excessivement longues

Causes des problèmes de performances des ressources

  • Insuffisance de maintenance
  • Derniers correctifs non appliqués
  • Optimisations non réalisées
  • Taille du serveur inadéquate vis-à-vis de la charge de l’utilisateur

Méthode d’analyse des problèmes de performances des ressources

Solutions aux problèmes courants de performances des ressources

Problèmes de mémoire

Symptômes d’un problème de mémoire

  • AEM se bloque inopinément et OutOfMemoryError est présent dans le journal
  • AEM devient de plus en plus lent et finit par se bloquer
  • AEM ne répond pas

Diagnostic d’un problème de mémoire

  • Recherchez des OutOfMemoryError dans les fichiers journaux, auquel cas vous êtes face à un problème de mémoire.
  • Examinez l’écran http://aem-host:port/system/console/memoryusage
    Une forte utilisation de « Ancienne génération » (JDK version 7 et précédentes) ou « Génération actuelle » (JDK version 8 ou ultérieure) peut être le signe d’un problème d’utilisation de la mémoire.  Cliquez sur « Exécuter le nettoyage de la mémoire » pour demander au JVM d’effectuer un nettoyage complet de la mémoire.  Si l’utilisation de la mémoire reste forte après avoir demandé un nettoyage, il y a probablement un problème.  Sur une instance AEM avec stockage Oak Tar, une utilisation supérieure à 3 Go est peut-être le signe d’un problème.  Une forte utilisation de la mémoire sur un système avec stockage Mongo peut être due à la configuration du cache en mémoire.
  • Prélevez des images mémoire de threads et le résultat de top, puis effectuez une analyse des threads.  Vérifiez si les threads responsables de la forte utilisation du processeur sont issus du nettoyage de la mémoire du JVM.  Si les threads mobilisant le plus le processeur sont les « threads VM » ou d’autres threads issus du nettoyage de la mémoire, il y a probablement un problème de mémoire.

Causes des problèmes de mémoire

  • Fuite de mémoire de l’application Java
  • Accumulation du finaliseur Java en raison d’une mauvaise utilisation de la finalisation du code personnalisé
  • Configuration de mémoire max. insuffisante

Méthode d’analyse de la cause du problème de mémoire

Pour plus d’informations sur la manière dont capturer une image mémoire des segments de mémoire, consultez cet article.

La meilleure façon de déterminer la cause d’un problème de mémoire est d’analyser une image mémoire des segments de mémoire.  

Dès lors que vous avez capturé un fichier d’image mémoire des segments de mémoire, ouvrez-le dans Eclipse MAT ou dans l’outil IBM Memory Analyzer.  Dans Eclipse MAT, exécutez le rapport de suspicions de fuites, puis ouvrez l’affichage « Détails des threads » pour voir les causes possibles du problème de mémoire.

Solutions aux problèmes de mémoire courants

  • Optimisez votre code d’application pour utiliser moins de mémoire si vous remarquez de longues pauses de nettoyage de la mémoire.  La plupart des problèmes de nettoyage de la mémoire peuvent être résolus en optimisant l’application par rapport au réglage du JVM.
  • Si vous avez déjà optimisé votre application et que vous continuez à rencontrer de longues pauses de nettoyage de la mémoire, concentrez-vous sur le réglage du JVM.

Problèmes d’indexation relatifs à AEM

Symptômes des problèmes d’indexation

Les éléments suivants sont les signes d’un problème d’indexation relatif à AEM/Oak :

  • Les résultats de la recherche sont obsolètes depuis plus de 10 minutes
  • Il manque certains résultats de la recherche
  • Des erreurs apparaissent dans l’IU ou les journaux lors d’une recherche via IU de site, une recherche de Query Builder ou une exécution de requête JCR
Diagnostic des problèmes d’indexation
  • Pour voir si l’indexation asynchrone est lente ou échoue, effectuez les étapes suivantes :

1. Ouvrez ces URL sur votre instance AEM pour afficher les statistiques sur le moteur d’indexation asynchrone

http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DIndexStats

http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dfulltext-async%2Ctype%3DIndexStats  - Cette URL ne s’applique qu’à AEM version 6.2 et ultérieure.

2. Sur chacune de ces pages, cochez les champs suivants :

FailingSince - Cela indique la date et l’heure du début de l’échec d’indexation.

LastError - Il s’agit de la trace de l’empilement indiquant ce qui cause l’échec de l’indexation.  S’il est vide, cela signifie que l’indexation fonctionne.

LastErrorTime - Cela indique la dernière fois où l’indexation a généré une erreur.

LastIndexedTime - Si la date et l’heure de ce champ remontent à plus de 5 minutes, l’indexation est trop lente.

Causes des problèmes d’indexation

  • Mauvaise maintenance ou absence de réalisation de celle-ci, dont le nettoyage de la mémoire de révision, la purge des flux de travail, la purge des audits, la purge des versions, etc.
  • Segments corrompus ou manquants dans le stockage Tar
  • Corruption de révision dans un environnement en cluster (DocumentNodeStore - Mongo ou base de données)
  • Problème de topologie de cluster dans un environnement en cluster

Méthode d’analyse de la cause des problèmes d’indexation

  • Pour savoir comment analyser et résoudre les problèmes d’indexation, consultez cet article.

Problèmes de réplication

Symptômes des problèmes de réplication

  • Les demandes de publication s’accumulent dans la file d’attente de l’agent de réplication.
  • Les contenus publiés n’apparaissent pas sur le serveur de publication.
  • Impact sur la performance du système

Causes des problèmes de réplication :

  • L’agent de réplication est mal configuré et ne peut pas se connecter à l’agent de publication.
  • Il y a une erreur au moment de la réplication qui bloque la file d’attente de réplication.
  • Le système est lent et les réplications sont traitées lentement.
  • La réplication s’effectue dans le cadre d’un processus personnalisé et le problème réside dans le traitement du processus.

Comment analyser les problèmes de réplication :

1. Vérifiez l’état de la file d’attente de réplication :

        Actif : lorsque les éléments sont en cours de traitement.
        Inactif : lorsque la file d’attente est vide.
        Bloqué : lorsque des éléments sont dans la file d’attente, mais ne peuvent pas être traités ; par exemple, lorsque l’agent pointe vers un hôte qui est en panne ou inexistant.

2. Vérifiez les configurations de réplication si votre serveur est cloné ou si l’agent a été configuré récemment. Pour plus d’informations, voir cette page
     
3. Consultez les journaux de l’agent de réplication à l’adresse http://host:port/etc/replication/agents.author/AgentName.log.html#end.  Si vous ne pouvez pas identifier d’éléments, recueillez ce journal et présentez-le au support AEM.

4. Vérifiez le fichier error.log du serveur à partir de AEMinstall/crx-quickstart/logs. Si vous ne pouvez identifier aucun élément, recueillez ce journal et présentez-le au support AEM.

5. Si la file d’attente de réplication est à l’état « inactif », et qu’aucune des conditions ci-dessus ne s’applique, dans cecasle problème est très probablement causé par les processus. Si les processus ne sont pas traités, l’élément de réplication n’arrive jamais dans la file d’attente de réplication. Pour surveiller l’état de vos processus, vous pouvez consulter le tableau de bord des processus afin de vérifier le nombre d’instances de processus en cours d’exécution. Pour en savoir plus sur l’administration des processus, cliquez ici.

6. Les réplications ralentissent lorsque le système est soumis à une charge élevée ou à d’autres problèmes de performance.

Solutions aux problèmes de réplication courants :

1) Examinez les problèmes de file d’attente de réplication.
2) Si le problème est dû au fait que les processus ne fonctionnent pas efficacement, vous pouvez consulter les conseils de traitement des processus simultanés
3) Pour les problèmes liés à la lenteur des performances globales d’AEM età la réplicationvous pouvez passer en revue les problèmes de performance d’AEM  

Problèmes de corruption TarMK

Symptômes d’une corruption TarMK

  • Instanceinutilisable après un compactage hors ligne.
  • Instance bloquée dans l’état Démarrage en cours.
  • Les fichiers journaux ou la sortie de la commande de compactage signalent une exception SegmentNotFoundException.

Causes des problèmes de corruption

  • Le segment est supprimé par une intervention manuelle (par exemple, rm -rf).   
  • Le segment est supprimé par le nettoyage de révision ou le segment est introuvable en raison d’un bogue dans le code.   
  • Le segment est introuvable en raison d’un bogue dans le code.
  • Diverses tâches de maintenance ne sont pas effectuées à temps, ce qui entraîne la croissance du référentiel et un faible espace disque.
  • Arrêtez de force AEM en tuant le processus java.

Diagnostic des problèmes de corruption du référentiel :

  • Examinez le fichier error.log et vérifiez s’il existe une exception SegmentNotFoundException ou IllegalArgument Exception.
  • Pour déterminer si un segment a été supprimé par le nettoyage de révision, vérifiez la sortie de org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC (enable debug log) logger. Cet enregistreur enregistre les identificateurs de segments de tous les segments supprimés lors de la phase de nettoyage. Ce n’est que lorsque l’identificateur du segment incriminé apparaît dans la sortie de cet enregistreur que le nettoyage de révision est la cause de l’exception.    
  • En cas de corruption dans un entrepôt de données externe, recherchez dans le fichier journal toutes les occurrences de l’erreur Une erreur s’est produite lors de l’obtention de InputStream pour blobId. Cette erreur signifie qu’il manque des fichiers dans le répertoire d’entrepôt de données AEM.

Solution aux problèmes de corruption :

  • Déterminez la dernière bonne révision connue de l’entrepôt de segments à l’aide du mode d’exécution (run-mode) check d’oak-run.  Rétablissez manuellement l’entrepôt de segments corrompu à sa dernière bonne révision. Cette opération rétablira le référentiel Oak à un état antérieur dans le temps.  Vous devez effectuer une sauvegarde complète du référentiel avant d’effectuer cette opération.
    • Pour effectuerla vérificationet restaurer, suivez les étapes mentionnées dans cet article.
    • Si la vérification échoue avec le message ConsistencyChecker - Aucune bonne révision n’a été trouvée, alors mettez en œuvre les étapes de la partie B de cet article.
  • Si vous utilisez déjà un entrepôt de données et que vous rencontrez l’erreur « Une erreur s’est produite lors de l’obtention de InputStream pour blobId », alors il manque probablement des fichiers dans l’entrepôt de données. Pour résoudre ce problème, lisez cet article.
  • Si vous n’utilisez pas d’entrepôt de données, utilisez un fichier externe, S3 ou Azure, au lieu de l’entrepôt de segmentspar défaut.
    • L’utilisation d’un entrepôt de données offre de meilleures performances.
    • Migrez l’instance vers une instance avec un entrepôt de données à l’aide de crx2oak.
  • Appliquez les derniers Service Pack, Cumulative Fix Pack et Oak Cumulative Fix Pack.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne