Cet article décrit les problèmes d’AEM critiques les plus courants et comment les analyser.
Symptômes d’un problème de performance
request.log
sur AEM affiche des temps de réponse lentsCauses des problèmes de performances
Comment analyser le problème de performances
1. Capturer une série de vidages de fils et analyser les
Vérifiez au niveau du système d’exploitation si l’AEM java
Le processus provoque une utilisation élevée du processeur
Linux: utilisez la commande supérieure pour vérifier l’utilisation du processeur.
Windows: utilisez la méthode Windows Gestionnaire des tâches
Si AEM cause une utilisation élevée du processeur, exécutez l’outil de profilage d’usine pendant quelques minutes et analysez le résultat.
1. Analyse du fichier request.log pour toutes les demandes lentes
Passez en revue les procédures de maintenance de votre système et assurez-vous que vous effectuez une maintenance correcte sur AEM, notamment :
Voir cet article pour plus d’informations sur la maintenance d’AEM.
Examinez les stratégies de mise en cache mises en oeuvre au niveau de la AEM niveau du dispatcher.
Vérification de la variable mise en cache.
Utilisez les outils d’analyse de site côté client tels que Audits fonctionnalité dans Google Chrome browser Outils de développement du panneau. Ces outils vous donneront des recommandations sur les améliorations de performances côté client.
Solutions aux problèmes de performances courants
Symptômes d’une Assets problème de performance
/assets.html
ou /damadmin
Interface utilisateurCauses des problèmes liés à Assets performance
Comment analyser la variable Assets problème de performance
Solutions communes Assets problèmes de performances
Symptômes d’un problème de mémoire
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 le site http://aem-host:port/system/console/memoryusage screen
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.
Récupération des images mémoire de threads et sortie supérieure et effectuez les opérations analyse des threads. 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.
Causes des problèmes de mémoire
Comment analyser la cause de votre problème de mémoire
Voir cet article pour plus d’informations sur la capture d’un vidage de tas.
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 Eclipse MAT ou IBM Memory Analyzer outil. 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
Symptômes des problèmes d’indexation
Voici les signes d’un problème lié à l’indexation AEM/Oak :
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 à AEM 6.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.
Causes des problèmes liés à l’indexation
Comment analyser les causes des problèmes d’indexation
Symptômes des problèmes de réplication
Causes des problèmes de réplication :
Comment analyser les problèmes de réplication :
Vérification de la file d’attente de réplication status:
Principal : 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 inexistant 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 here.
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, collectez ce journal et présentez-le pour AEM la prise en charge.
Vérification du serveur error.log
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 "inactive" 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 here.
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 :
Si le problème est dû au mauvais fonctionnement des workflows, vous pouvez consulter le conseils de traitement des workflows
Symptômes de corruption TarMK
Ce qui cause les problèmes de corruption
Diagnostic des problèmes de corruption du référentiel :
Solution aux problèmes de corruption :