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
Problèmes de performances d’AEM Sites
Symptômes d’un problème de performance
Chargement lent des pages
Création ou modification des pages lentes
Les temps de réponse AEM sont lents
AEM ne répond pas pour certaines requêtes
request.log sur AEM affiche des temps de réponse lents
Causes des problèmes de performances
Contention de threads : demandes longues 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 du HTML
Taille de serveur insuffisante ou architecture incorrecte
Vérifiez au niveau du système d’exploitation si le processus java AEM provoque une utilisation élevée du processeur : 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.
Linux : utilisez la commande supérieure pour vérifier l’utilisation du processeur.
Passez en revue les procédures de maintenance de votre système. Voir article pour plus d’informations sur la maintenance d’AEM et pour vous assurer que vous effectuez 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
Examinez les stratégies de mise en cache mises en oeuvre au niveau de la AEM niveau du dispatcher.
Utilisez les outils d’analyse de site côté client tels que Audits fonctionnalité dans le navigateur Google Chrome 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
Voir cet article pour obtenir des instructions détaillées sur les moyens d’optimiser les performances.
Des solutions à certains scénarios de problèmes et à leurs solutions sont disponibles here.
Pour optimiser 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 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
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
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
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.
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 - This L’URL s’applique uniquement à AEM version 6.2 et ultérieure.
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
Une maintenance incorrecte ou l’échec d’exécution de la maintenance, comme 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 les causes des problèmes d’indexation
Voir cet article pour l’analyse et la résolution des problèmes d’indexation
Problèmes de réplication
Symptômes des problèmes de réplication
Les requêtes de publication 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érification de la file d’attente de réplication status:
Principal : lorsque des éléments sont en cours de traitement.
Idle : 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.
Examinez le fichier error.log du serveur 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.
L’instance est inutilisable après un compactage hors ligne.
Instance bloquée Démarrage en cours état.
Fichiers journaux ou rapport de sortie de commande de compression SegmentNotFoundException.
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 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 :
Consultez le fichier error.log et vérifiez s’il existe des SegmentNotFoundException ou Exception IllegalArgument.
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 d’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 aux problèmes de corruption :
Déterminez la dernière révision correcte connue de l’entrepôt de segments à l’aide de la variable check run-mode de oak-run. Rétablissez manuellement le magasin de segments corrompu à sa dernière bonne révision. Cette opération rétablit l’état précédent du référentiel Oak dans le temps. Vous devez sauvegarder complètement le référentiel avant d’effectuer cette opération.
Pour effectuer une vérification et une restauration, procédez comme indiqué dans cet article.
Si la vérification échoue avec ConsistencyChecker - Aucune bonne révision n’a été trouvée implémenter ensuite 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.
Migration de 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.