Comment analyser les problèmes d’AEM critiques courants
Découvrez les problèmes d’AEM critiques les plus courants et comment les analyser.
Description description
Environnement
Adobe Experience Manager (AEM)
Problème/Symptômes
Cet article décrit les problèmes d’AEM critiques 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 TarMK
Résolution resolution
Problèmes de performances d’AEM Sites
Symptômes d'un problème de performances
- Chargement lent des pages
- Création ou modification des pages lentes
- Les temps de réponse AEM sont lents
- AEM ne répond pas à certaines requêtes
- request.log sur AEM affiche des temps de réponse lents
Ce qui cause des problèmes de performances
- Contention de threads : demandes de longue durée telles que les recherches lentes, les tâches en arrière-plan encombrées d’écriture, le déplacement de branches entières du contenu du site, etc.
- Utilisation élevée du processeur
- Demandes coûteuses, telles que des recherches coûteuses ou un code d’application inefficace, des composants, etc.
- Manque de maintenance
- Mise en cache insuffisante du Dispatcher
- Absence de réseau de diffusion de contenu
- Absence de mise en cache du navigateur
- Trop de scripts chargés sur la page et chargés en haut de la page
- CSS chargé sur toute la page au lieu de dans l’en-tête de l’HTML
- Taille de serveur insuffisante ou architecture incorrecte
- Problèmes de mémoire (voir ci-dessous)
Comment analyser le problème de performances
-
Vérifiez au niveau du système d’exploitation si le processus Java d’AEM provoque une utilisation élevée du processeur : si AEM cause une utilisation élevée du processeur, exécutez l’outil de profilage prêt à l’emploi pendant quelques minutes et analysez le résultat.
- Linux : utilisez la commande supérieure pour vérifier l’utilisation du processeur.
- Fenêtre : utilisez le Gestionnaire de tâches Windows
-
Analysez le fichier request.log pour toutes les demandes lentes.
-
Passez en revue les procédures de maintenance de votre système. Consultez cet article pour plus d’informations sur la maintenance AEM et assurez-vous d’effectuer une maintenance correcte sur AEM, notamment :
- Nettoyage des révisions (MongoMK et Database DocumentNodeStore uniquement) - quotidien ou plus fréquent
- Compression Tar hors ligne (TarMK uniquement) - bi-hebdomadaire
- Nettoyage de la mémoire d’entrepôt 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
-
Passez en revue les stratégies de mise en cache mises en oeuvre au niveau AEM dispatcher.
-
Examinez la mise en cache de votre site.
-
Utilisez des outils d’analyse de site côté client tels que la fonctionnalité Audits dans le panneau Outils de développement du navigateur Google Chrome. Ces outils vous donneront des recommandations sur les améliorations de performances côté client.
Solutions aux problèmes de performances courants
- Reportez-vous à cet article pour obtenir des instructions détaillées sur les façons d’optimiser les performances.
- Consultez les conseils d’optimisation des performances
Problèmes de performances d’Assets
Symptômes d’un problème de performances Assets
- Téléchargements de fichiers lents vers /assets.html ou /damadmin UI
- La génération des miniatures prend trop de temps.
- Les opérations Assets telles que déplacer, supprimer, modifier et mettre à jour des métadonnées prennent trop de temps.
Ce qui entraîne des problèmes avec les performances d’Assets
- Manque de maintenance
- Derniers packs de correctifs non appliqués
- Optimisations non appliquées
- Dimensionnement insuffisant du serveur pour le chargement de l’utilisateur
Comment analyser le problème de performances Assets
Solutions aux problèmes de performances courants d’Assets
- Examinez le Guide d’optimisation des performances d’AEM Assets.
- Les solutions à certains scénarios de problèmes et leurs solutions sont disponibles ici.
- Réglez les performances de traitement des ressources, voir cet article.
Problèmes de mémoire
Symptômes d'un problème de mémoire
- AEM se bloque de manière aléatoire et dans les journaux OutOfMemoryError est observé.
- AEM devient plus lent au fil du temps et finit par se bloquer
- AEM ne répond pas
Diagnostic d’un problème de mémoire
-
Recherchez les fichiers journaux pour OutOfMemoryError. Si vous trouvez des correspondances, un problème de mémoire se produit.
-
Consultez l’écran http://aem-host:port/system/console/memoryusage
Si l’utilisation de "l’ancienne génération" (JDK 7 et antérieure) ou de "génération assurée" (JDK 8 ou version ultérieure) est élevée, cela peut être le signe d’un problème d’utilisation de la mémoire de tas. Cliquez sur "Lancer le nettoyage de la mémoire" pour demander à la JVM d’exécuter un nettoyage de la mémoire de tas complet. Si l’utilisation élevée du tas reste élevée après avoir demandé du GC, il y a probablement un problème. Sur une instance d’AEM avec stockage Oak Tar, si l’utilisation continue est supérieure à 3 Go, un problème peut se produire. Une utilisation élevée du tas sur un système avec stockage Mongo peut être due à la configuration du cache en mémoire.
-
Prenez les thread dumps et la sortie supérieure et effectuez l’ analyse de thread. Vérifiez si les threads à l’origine d’une utilisation élevée du processeur sont des threads de nettoyage de la mémoire JVM natifs. Si le thread utilisant le plus de temps CPU est le "thread VM" ou tout autre thread de nettoyage de la mémoire, il y a probablement un problème de mémoire.
Ce qui cause des problèmes de mémoire
- Fuite de mémoire d’application Java
- Le Finalizer Java s’empile en raison d’une utilisation incorrecte de la finalisation dans le code personnalisé.
- Configuration de tas maximale insuffisante
Comment analyser la cause de votre problème de mémoire
Pour plus d'informations sur la capture d'un vidage de tas, voir cet article .
La meilleure façon d’identifier la cause d’un problème de mémoire consiste à analyser un vidage de tas.
Une fois que vous avez capturé un fichier de vidage de tas, ouvrez-le dans l’outil Eclipse MAT ou IBM Memory Analyzer. Dans Eclipse MAT, exécutez le rapport Leak Suspects et ouvrez la vue "Thread Details" pour voir les causes potentielles du problème de mémoire.
Solutions aux problèmes de mémoire courants
- Optimisez le code de votre application afin d’utiliser moins de mémoire si vous constatez que le nettoyage de la mémoire est en pause. La plupart des problèmes de nettoyage de la mémoire peuvent être résolus en optimisant l’application plutôt que en réglant la JVM.
- Si vous avez déjà optimisé votre application et que vous rencontrez toujours de longues pauses GC, alors concentrez-vous sur l’optimisation de la JVM.
AEM problème d’indexation
Symptômes de problèmes d’indexation
Voici les signes d’un 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 les journaux pendant 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 vérifier si l’indexation asynchrone est lente ou échoue, procédez comme suit :
-
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 versions ultérieures.
-
Sur chacune de ces pages, vérifiez les champs suivants :
FailingSince : cela indique quand l’indexation a commencé à échouer.
LastError - Il s’agit de la trace de la pile montrant ce qui provoque 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 ont plus de 5 minutes, l’indexation est trop lente.
Ce qui provoque des problèmes avec l’indexation
- Une maintenance incorrecte ou l’échec de la maintenance, par exemple le nettoyage de la mémoire de révision, la purge du workflow, la purge du contrôle, la purge de version, etc.
- Segments corrompus ou manquants dans le stockage Tar
- Révision de la corruption dans un environnement organisé en grappes (DocumentNodeStore - Mongo ou base de données)
- Problème avec la topologie de grappe dans un environnement organisé en grappe
Comment analyser ce qui provoque 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 Publish sont 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
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 s’est produite au moment de la réplication, provoquant le blocage de 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 des workflows.
Comment analyser les problèmes de réplication :
-
Vérifiez la file d’attente de réplication status :
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 qui est en panne ou inexistant.
-
Vérifiez les configurations de réplication si votre serveur est cloné ou si l’agent a été récemment configuré. Pour plus d'informations, voir ici.
-
Passez en revue 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, collectez ce journal et présentez-le pour AEM la prise en charge.
-
Examinez le fichier error.log du serveur à partir de AEMinstall/crx-quickstart/logs ; si vous ne pouvez pas identifier d’éléments, collectez ce journal et présentez-le pour AEM la prise en charge.
-
Si la file d’attente de réplication est à l’état "inactif" et qu’aucune des conditions ci-dessus ne s’applique, le problème est probablement dû aux workflows. Si les workflows ne sont pas en cours de traitement, l’élément de réplication n’atteint jamais la file d’attente de réplication. Pour surveiller l’état de vos workflows, vous pouvez consulter le tableau de bord du workflow afin de vérifier le nombre d’instances de workflow en cours d’exécution. Vous pouvez en savoir plus sur l'administration des workflows ici.
-
Les réplications ralentissent lorsque le système est soumis à une charge élevée ou rencontre d’autres problèmes de performances.
Solution aux problèmes de réplication courants :
- Examinez les problèmes de file d’attente de réplication.
- Si le problème est dû au mauvais fonctionnement des workflows, vous pouvez consulter les conseils de traitement des workflows simultanés.
Problèmes de corruption TarMK
Symptômes de corruption TarMK
- L’instance est inutilisable 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 compression SegmentNotFoundException.
Ce qui cause 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 la mémoire de révision ou le segment est introuvable en raison d’un bogue 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 faible espace disque.
- Arrêter l'AEM par la force 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 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 (activation du journal de débogage). Ce journal consigne les identifiants de segment de tous les segments supprimés lors de la phase de nettoyage. Ce n’est que lorsque l’identifiant de segment offensant 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 la banque 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 que vous ne disposez pas de fichiers dans votre répertoire de banque de données AEM.
Solution pour résoudre les problèmes de corruption :
-
Déterminez la dernière bonne révision connue du magasin de segments à l’aide du mode d’exécution check de oak-run. Rétablissez manuellement le magasin de segments corrompu à sa dernière bonne révision. Cette opération rétablit 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 effectuer la vérification et la restauration, suivez les étapes mentionnées dans cet article.
- Si la vérification échoue avec ConsistencyChecker - Aucune bonne révision trouvée, implémentez les étapes de la partie B de cet article.
-
Si vous n’utilisez pas de banque de données, utilisez un fichier externe, S3 ou Azure datastore, au lieu de l’entrepôt de segments par défaut.
- L’utilisation d’une banque de données offre de meilleures performances.
- Migrez l’instance vers une instance avec banque de données à l’aide de crx2oak.
-
Appliquez les derniers Service Pack et Cumulative Fix Pack et Oak Cumulative Fix Pack.