Problèmes d’AEM critiques courants

Description

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

  1. Chargement lent des pages
  2. Création ou modification des pages lentes
  3. Les temps de réponse AEM sont lents
  4. AEM ne répond pas pour certaines requêtes
  5. request.log sur AEM affiche des temps de réponse lents

Causes des problèmes de performances

  1. 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.
  2. Utilisation élevée du processeur
  3. Demandes coûteuses, telles que des recherches coûteuses ou un code d’application inefficace, des composants, etc.
  4. Manque de maintenance
  5. Mise en cache insuffisante du Dispatcher
  6. Absence de réseau de diffusion de contenu
  7. Absence de mise en cache du navigateur
  8. Trop de scripts chargés sur la page et chargés en haut de la page
  9. CSS chargé sur toute la page au lieu de dans l’en-tête du HTML
  10. Taille de serveur insuffisante ou architecture incorrecte
  11. Problèmes de mémoire (voir ci-dessous)

Comment analyser le problème de performances

  1. Capturer une série de vidages de fils et analyser les.
  2. 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.
    • Fenêtre : Utilisation de Windows Task Manager
  3. Analyse du fichier request.log pour toutes les demandes lentes.
  4. 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
  5. Examinez les stratégies de mise en cache mises en oeuvre au niveau de la AEM niveau du dispatcher.
  6. Vérification de la variable mise en cache.
  7. 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


 Problèmes de performances des ressources

Symptômes d’un problème de performances d’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 de ressources telles que le déplacement, la suppression, la modification et la mise à jour des métadonnées prennent trop de temps.

Ce qui entraîne des problèmes de performances des ressources

  • Manque de maintenance
  • Derniers packs de correctifs non appliqués
  • Optimisations non appliquées
  • Dimensionnement insuffisant du serveur pour le chargement de l’utilisateur

Analyse du problème de performances d’Assets

Solutions aux problèmes de performances courants des ressources

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.
  • Si vous avez déjà optimisé votre application et que vous rencontrez toujours de longues pauses GC, alors se concentrer sur l’optimisation de la JVM.

AEM problème d’indexation
 

Symptômes des 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 :

  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  - This L’URL s’applique uniquement à AEM version 6.2 et ultérieure.

  2. 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 :

  1. 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.

  2. 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.

  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, collectez ce journal et présentez-le pour AEM la prise en charge.

  4. 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.

  5. 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.

  6. 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 :

  1. Examinez les problèmes de file d’attente de réplication..
  2. Si le problème est dû au mauvais fonctionnement des workflows, vous pouvez consulter le conseils de traitement des workflows.

Problèmes de corruption TarMK
 

Symptômes de corruption TarMK

  • 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.

Sur cette page