L’utilisation du disque est inhabituellement élevée ou augmente rapidement sur le serveur AEM

Découvrez comment identifier les causes d’une utilisation élevée du disque sur le serveur AEM. Utilisez un enregistreur de débogage, capturez les images mémoire de threads et définissez les profils de CPU, puis exécutez le rapport d’utilisation du disque.

Description description

Environnement

Adobe Experience Manager

Problème/Symptômes

L’utilisation du disque est inhabituellement élevée ou augmente rapidement sur un serveur AEM. L’espace disque étant épuisé, AEM a cessé de fonctionner.

Résolution resolution

A. Si AEM est en cours d’exécution et que l’espace disque est suffisant

  1. Configurer la journalisation de trace d’écriture oak Si AEM est toujours en cours d’exécution, nous pouvons activer un enregistreur de débogage pour nous indiquer les chemins de référentiel sur lesquels sont écrites. Pour activer cet enregistreur, installez le package de configuration du journal ci-joint ou procédez comme suit :

    1. Accédez à https://aemhost:port/system/console/slinglog
    2. Cliquez sur Ajouter un nouvel enregistreur.
    3. Configurez un enregistreur : Fichier journal : logs/repgrowth.log, Niveau de journal : trace, Enregistreurs : org.apache.jackrabbit.oak.jcr.operations.writes
    4. Téléchargez fichier. Ce package contient la configuration requise pour la session d’écriture de journalisation pour Oak. Installez ce package via le gestionnaire de packages CRX. Après la période de votre moniteur, veillez à désinstaller le package.

    Attention

    • Le journal contient des informations concernant toutes les écritures et les détails de session. Si vous utilisez cet enregistreur, vérifiez que vous disposez d’un espace disque suffisant.
    • Désinstallez le package de configuration du journal ou supprimez la configuration du journal après une courte période d’activation afin d’éviter une consommation d’espace disque supplémentaire.
  2. Exécuter le rapport d'utilisation du disque Vous pouvez également utiliser le rapport d’utilisation du disque https://host:port/etc/reports/diskusage.html. Ce rapport affiche l’espace disque utilisé par le chemin du référentiel. Le rapport peut être consulté, ce qui vous permet d’afficher également les sous-arborescences.

  3. Capturer des images mémoire de threads et établir des profils Après avoir utilisé repgrowth.log pour avoir une idée des données écrites, nous pouvons obtenir des informations sur le code qui écrit ces données en capturant des images mémoire de threads et en exécutant le profilage CPU. Consultez ces pages :

B. Si AEM s’est arrêté et/ou que l’espace disque est presque plein

Si vous avez dû arrêter AEM pour éviter l’augmentation de l’espace disque, utilisez les commandes ci-dessous pour effectuer une analyse initiale.

  • Sur la plateforme Linux, utilisez la commande du pour répertorier tous les répertoires sous crx-quickstart avec la taille résumée de ces répertoires :

    code language-none
    du -h --max-depth=2 crx-quickstart
    
  • Utilisez les commandes find et du pour rechercher les fichiers récemment modifiés et obtenir leur taille :

    code language-none
    find crx-quickstart -type f -mtime 1 -exec du -hs {} \; -print
    
  • Pour rechercher des fichiers volumineux dans le magasin de données, vous pouvez combiner les commandes find, du et file pour rechercher des fichiers sur 100MB dans le répertoire datastore et identifier automatiquement leur type de fichier :

    code language-none
    find crx-quickstart/repository/datastore -type f -size +100M -exec sh -c "du -hs \"{}\"; file \"{}\"" \;
    
  • Si vous constatez une croissance dans le répertoire segmentstore, la commande ci-dessous peut vous aider à indiquer les données en cours d’écriture :

    code language-none
    strings data_xxxxxx.tar | egrep '.?/' | sed 's/.$//;s/.\//\//'
    

Cause

Voici quelques causes potentielles d'augmentations inhabituelles de l'utilisation du disque :

  • Aucune maintenance appropriée n’a été effectuée sur le système.  Voir cet article pour plus d’informations sur les différentes activités de maintenance du système.
  • AEM ou l’application crée un très grand nombre de nœuds ou met à jour les propriétés des nœuds.  Cela peut être dû à une mauvaise configuration ou à un bug de code d’application.  Étant donné que le stockage tar dans Oak fonctionne en mode d’ajout uniquement, l’enregistrement répété des nœuds contribue en outre à la croissance excessive du référentiel.
  • Un ou plusieurs fichiers très volumineux ont été chargés vers AEM Assets ou le gestionnaire de packages.
  • La journalisation du débogage ou de la trace n’a pas été activée.
recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f