Documentation

Comment analyser les problèmes critiques courants d’AEM

Last update: Mon Sep 15 2025 00:00:00 GMT+0000 (Coordinated Universal Time)

Découvrez les problèmes critiques les plus courants d’AEM et comment les analyser.

Description description

Environnement

Adobe Experience Manager (AEM)

Problème/Symptômes

Cet article décrit les problèmes critiques d’AEM les plus courants et comment les analyser.

  • Performances d’AEM Sites
  • Performances d’AEM Assets
  • Problèmes de mémoire
  • Problèmes d'indexation
  • Problèmes de réplication
  • Problèmes de corruption de TarMK

Résolution resolution

Problèmes de performances d’AEM Sites

Symptômes d’un problème de performances

  1. Chargement lent des pages
  2. Création ou modification lente des pages
  3. Les temps de réponse d’AEM sont lents
  4. AEM ne répond pas à certaines demandes
  5. Le fichier request.log sur AEM affiche des temps de réponse lents

Qu’est-ce qui cause des problèmes de performances

  1. Contention des threads : requêtes de longue durée telles que les recherches lentes, les tâches en arrière-plan gourmandes en écriture, le déplacement de branches entières du contenu du site, etc.
  2. Utilisation élevée de CPU
  3. Les demandes coûteuses telles que les recherches coûteuses ou le code d’application inefficace, les composants, etc.
  4. Manque d’entretien
  5. Mise en cache insuffisante du Dispatcher
  6. Absence de réseau CDN
  7. Absence de mise en cache du navigateur
  8. Trop de scripts chargés sur la page en haut de la page
  9. CSS chargé dans toute la page au lieu de dans l’en-tête HTML
  10. Taille du serveur insuffisante ou architecture incorrecte
  11. Problèmes de mémoire (voir ci-dessous)

Comment analyser le problème de performances

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

  2. Vérifiez au niveau du système d’exploitation si le processus Java AEM provoque une utilisation élevée du CPU : si AEM provoque une utilisation élevée du CPU, exécutez l’outil de création de profils prêt à l’emploi pendant quelques minutes et analysez le résultat.

    • Linux : utilisez la commande supérieure pour vérifier l’utilisation de CPU.
    • Fenêtre : utiliser le Gestionnaire des tâches de Windows

  3. Analysez le fichier request.log pour détecter les demandes lentes.

  4. Examinez les procédures de maintenance de votre système. Voir cet article pour plus d’informations sur la maintenance d’AEM et pour vous assurer que vous effectuez la maintenance appropriée sur AEM, notamment :

    • Nettoyage des révisions (MongoMK et Database DocumentNodeStore uniquement) - quotidien ou plus fréquent
    • Compression du fichier Tar hors ligne (TarMK uniquement) - deux fois par semaine
    • Récupération de l’espace mémoire du magasin de données (systèmes avec FileDataStore ou S3 DataStore uniquement) - hebdomadaire
    • Purge du workflow - hebdomadaire
    • Purge de version - hebdomadaire
    • Purge du journal d’audit - hebdomadaire

  5. Examinez les stratégies de mise en cache implémentées au niveau du Dispatcher AEM.

  6. Vérifiez la mise en cache de votre site.

  7. Utilisez les outils d’analyse de site côté client tels que la fonctionnalité Audits du navigateur Google Chrome panneau Outils de développement. Ces outils vous donnent des recommandations sur les améliorations des performances côté client.

Solutions aux problèmes de performances courants

Problèmes de performances d’Assets

Symptômes d’un problème de performances Assets

  • Chargements de fichiers lents vers /assets.html ou l’interface utilisateur /damadmin
  • La génération des miniatures prend trop de temps.
  • Les opérations Assets telles que le déplacement, la suppression, la modification et la mise à jour des métadonnées prennent trop de temps

Quelles sont les causes des problèmes de performances d’Assets

  • Manque d’entretien
  • Derniers packs de correctifs non appliqués
  • Optimisations non appliquées
  • Dimensionnement du serveur inadéquat pour le chargement de l’utilisateur

Comment analyser le problème de performances d’Assets

Solutions aux problèmes de performances courants d’Assets

Problèmes de mémoire

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

  • AEM se bloque de manière aléatoire et une erreur OutOfMemory est observée dans les journaux
  • AEM ralentit au fil du temps et finit par se bloquer
  • AEM ne répond pas

Diagnostic d’un problème de mémoire

  • Recherchez OutOfMemoryError dans les fichiers journaux. Si vous trouvez des correspondances, vous rencontrez un problème de mémoire

  • Examinez l’écran http://aem-host:port/system/console/memoryusage .

    Si l’utilisation de « l’ancienne génération » (JDK 7 et versions antérieures) ou de « la génération persistante » (JDK8 ou versions ultérieures) est élevée, cela peut être le signe d’un problème d’utilisation de la mémoire de tas. Cliquez sur « Exécuter le nettoyeur de la mémoire » pour demander à la JVM d’exécuter un nettoyage complet de la mémoire. Si l’utilisation élevée du tas reste élevée après avoir demandé du GC, cela peut poser un problème. Sur une instance AEM avec un stockage Oak Tar, si l’utilisation persistante est supérieure à 3 Go, un problème peut se produire. Une utilisation élevée du tas sur un système avec un stockage Mongo peut être due à la configuration du cache en mémoire.

  • Prenez des images mémoire de threads et une sortie supérieure et effectuez une analyse des threads. Vérifiez si les threads entraînant une utilisation élevée de CPU sont des threads de récupération de l’espace mémoire JVM natifs. Si le thread qui utilise le plus de temps CPU est le « thread VM » ou tout autre thread de récupération de l’espace mémoire, il y a probablement un problème de mémoire.

Qu’est-ce qui cause des problèmes de mémoire

  • Fuite de mémoire de l’application Java
  • Le finaliseur Java s’empile en raison d’une utilisation incorrecte de la finalisation dans le code personnalisé
  • Configuration maximale du tas insuffisante

Comment analyser la cause de votre problème de mémoire

Voir cet article pour plus d’informations sur la capture d’une image mémoire.

La meilleure façon d’identifier la cause d’un problème de mémoire consiste à analyser une image mémoire.

Une fois que vous avez capturé un fichier d’image mémoire, ouvrez-le dans l’outil Eclipse MAT ou IBM Memory Analyzer. Dans Eclipse MAT, exécutez le rapport Leak Suspects et ouvrez la vue « Détails du thread » pour identifier les causes potentielles du problème de mémoire.

Solutions aux problèmes courants de mémoire

  • Optimisez le code de votre application pour utiliser moins de mémoire si vous remarquez de longues pauses de récupération de l’espace mémoire. La plupart des problèmes de récupération de l’espace mémoire peuvent être résolus en optimisant l’application plutôt qu’en réglant la JVM.
  • Si vous avez déjà optimisé votre application et que vous faites toujours l’expérience de longues pauses GC, concentrez-vous sur le réglage de la JVM.

Problème d’indexation AEM

Symptômes des problèmes d’indexation

Voici des signes de problème lié à l’indexation AEM/Oak :

  • Les résultats de recherche sont obsolètes de plus de 10 minutes
  • Il manque des résultats de recherche
  • Les erreurs sont renvoyées dans l’interface utilisateur ou dans les journaux lors de la recherche via l’interface utilisateur du site, la recherche Query Builder ou l’exécution de requêtes JCR

Diagnostic d’un problème d’indexation

Pour déterminer si l’indexation asynchrone est lente ou échoue, procédez comme suit :

  1. Ouvrez ces URL sur votre instance AEM pour afficher les statistiques sur l’indexeur 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 s’applique uniquement à AEM6.2 et aux versions ultérieures

  2. Vérifiez les champs suivants sur chacune de ces pages :

    FailingSince - Indique à quel moment l’indexation a commencé à échouer.

    LastError - Il s’agit de la trace de la pile qui indique ce qui cause l’échec de l’indexation. Si ce champ est vide, l’indexation n’échoue pas.

    LastErrorTime - Indique la dernière fois que l’indexation a généré l’erreur.

    LastIndexedTime - Si la date et l’heure de ce champ datent de plus de 5 minutes, l’indexation s’exécute trop lentement.

Quelles sont les causes des problèmes d’indexation

  • Mauvaise maintenance ou échec de maintenance tel que le nettoyage de la mémoire de révision, la purge du workflow, la purge d’audit, la purge de version, etc.
  • Segments corrompus ou manquants dans le stockage Tar
  • Révision corrompue dans un environnement en cluster (DocumentNodeStore - Mongo ou Database)
  • Un problème lié à la topologie du cluster dans un environnement en cluster

Comment analyser ce qui cause des problèmes d’indexation

  • Voir cet article pour analyser et résoudre les problèmes d’indexation

Problèmes de réplication

Symptômes des problèmes de réplication

  • Les requêtes de publication sont placées en file d’attente dans la file d’attente de l’agent de réplication
  • Les contenus publiés ne s’affichent pas sur le serveur de publication
  • Impact sur les performances du système

Quelles sont les 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
  • Une erreur se produit au moment de la réplication, ce 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 workflow personnalisé et le problème est lié au traitement du workflow.

Comment analyser les problèmes de réplication :

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

    Actif : lorsque des éléments sont en cours de traitement.

    Inactif : lorsque la file d’attente est vide.

    Bloqué : lorsque des éléments se trouvent dans la file d’attente, mais ne peuvent pas être traités ; par exemple, lorsque l’agent pointe vers un hôte inactif 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, rendez-vous ici.

  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 parvenez pas à identifier un élément, collectez ce journal et présentez-le à l’assistance AEM.

  4. Consultez le fichier error.log du serveur AEMinstall/crx-quickstart/logs ; si vous ne parvenez pas à identifier un élément, collectez ce journal et présentez-le à l’assistance 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 ce cas, le problème est probablement dû aux workflows. Si les workflows ne sont pas traités, l’élément de réplication n’atteint jamais la file d’attente de réplication. Pour surveiller le statut de vos workflows, vous pouvez vérifier le tableau de bord des workflows pour vérifier le nombre d’instances de workflows en cours d’exécution. Vous pouvez en savoir plus sur l’administration des workflows ici.

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

Solution aux problèmes courants de réplication :

  1. Consultez les problèmes de file d’attente de réplication.
  2. Si le problème est dû à l’exécution inefficace des workflows, vous pouvez consulter les conseils de traitement des workflows simultanés.

Problèmes de corruption de TarMK

Symptômes de la corruption de TarMK

  • L’instance ne fonctionne pas après le compactage hors ligne.
  • L’instance est bloquée à l’état Démarrage en cours.
  • Fichiers journaux ou rapport de sortie de commande de compression SegmentNotFoundException.

Qu’est-ce qui cause les problèmes de corruption

  • Le segment est supprimé par une intervention manuelle (par exemple, rm -rf ).
  • Le segment est supprimé par la récupération de l’espace mémoire de révision ou il est introuvable en raison d’un bug dans le code.
  • Le segment est introuvable en raison d’un bug dans le code.
  • Diverses tâches de maintenance ne sont pas effectuées à temps, ce qui entraîne une croissance du référentiel et un espace disque faible.
  • Arrêt forcé d’AEM en supprimant le processus Java.

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

  • Consultez 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 la mémoire de révision, vérifiez la sortie de l’enregistreur org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC (activer le journal de débogage). Cet enregistreur consigne les identifiants de segment de tous les segments supprimés par la phase de nettoyage. Ce n’est que lorsque l’identifiant de segment incriminé apparaît dans la sortie de cet enregistreur que le nettoyage de la mémoire de révision est la cause de l’exception.
  • En cas de corruption dans le magasin de données externe, recherchez dans le fichier journal toutes les occurrences d’erreur Une erreur s’est produite lors de l’obtention de InputStream pour blobId. Cette erreur signifie qu’il vous manque des fichiers dans le répertoire du magasin de données AEM.

Solution pour résoudre les problèmes de corruption :

  • Déterminez la dernière révision correcte connue de l’entrepôt de segments à l’aide du mode d’exécution check d’oak-run. Rétablissez manuellement le magasin de segments corrompu à sa dernière bonne révision. Cette opération rétablit dans le temps l’état précédent du référentiel Oak. Vous devez effectuer une sauvegarde complète du référentiel avant d’effectuer cette opération.

    • Pour effectuer une vérification et une restauration, suivez les étapes mentionnées dans cet article.
    • Si la vérification échoue avec ConsistencyChecker - Aucune révision correcte trouvée alors implémentez les étapes de la partie B de cet article.

  • Si vous n’utilisez pas de magasin de données, utilisez un fichier externe, un magasin de données S3 ou Azure, au lieu du magasin de segments par défaut.

    • L’utilisation d’un magasin de données offre de meilleures performances.
    • Migrez l’instance vers une instance avec un magasin de données à l’aide de crx2oak.

  • Appliquez le dernier pack de services et le pack de correctifs cumulés ainsi que le pack de correctifs cumulés Oak.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f