L’utilisation du disque est exceptionnellement élevée ou en augmentation rapide sur AEM serveur
Découvrez comment identifier les causes d’une utilisation élevée du disque sur AEM Server. Utilisez un enregistreur de débogage, capturez les images mémoire de threads et effectuez le profilage du processeur, puis exécutez le rapport sur l’utilisation du disque.
Description description
Environnement
Adobe Experience Manager
Problème/Symptômes
L’utilisation du disque est exceptionnellement élevée ou en augmentation rapide sur un serveur AEM. L’espace disque étant saturé, AEM a cessé de fonctionner.
Résolution resolution
A. Si AEM est en cours d’exécution et qu’il y a un espace disque important
-
Configuration de 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 dans lesquels sont écrits. Pour activer ce journal, installez le package de configuration du journal joint ci-dessous ou procédez comme suit :
- Accédez à https://aemhost:port/system/console/slinglog
- Cliquez sur Ajouter un nouvel enregistreur.
- Configurez un journal : Fichier journal : logs/repgrowth.log, Niveau de journal : trace, Enregistreurs : org.apache.jackrabbit.oak.jcr.operations.writes
- Téléchargez file. Ce package contient la configuration requise pour la session d’écriture de journalisation pour Oak. Installez ce package via le Gestionnaire de modules CRX. Après la période de contrôle, veillez à désinstaller le package.
Attention
- Le journal contient des informations concernant toutes les écritures et tous les détails de session. Si vous utilisez cet enregistreur, assurez-vous que vous disposez de suffisamment d’espace disque.
- Désinstallez le package de configuration du journal ou supprimez la configuration du journal après une courte période de temps, afin d’éviter toute consommation d’espace disque supplémentaire.
-
Exécutez le rapport sur l’utilisation du disque Vous pouvez également exploiter le rapport 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 percé, ce qui vous permet également d’afficher les sous-arborescences.
-
Capture des images mémoire de threads et création de profils Après avoir utilisé repGrowth.log pour avoir une idée des données en cours d’écriture, 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 du processeur. Consultez les pages suivantes :
B. Si AEM a été arrêté et/ou que l'espace disque est presque plein
Si vous deviez arrêter AEM afin d'é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 des fichiers récemment modifiés et obtenir leurs tailles :
code language-none find crx-quickstart -type f -mtime 1 -exec du -hs {} \; -print -
Pour rechercher des fichiers volumineux dans la banque de données, vous pouvez combiner les commandes find, du et file pour rechercher des fichiers de plus de 100 Mo 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 que la croissance se produit dans le répertoire segmentstore, la commande ci-dessous peut aider à indiquer quelles données sont écrites :
code language-none strings data_xxxxxx.tar | egrep '.?/' | sed 's/.$//;s/.\//\//'
Cause
Voici quelques causes potentielles d’augmentation inhabituelle de l’utilisation du disque :
- Aucune maintenance correcte n’a été effectuée sur le système. Consultez 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 noeuds ou de mises à jour des propriétés de noeud. Cela peut être dû à une mauvaise configuration ou à un bogue du code de l’application. Comme le stockage tar dans Oak fonctionne en mode append uniquement, l’enregistrement répété des noeuds contribue à une croissance excessive du référentiel.
- Un ou plusieurs fichiers très volumineux ont été chargés dans AEM Assets ou le gestionnaire de modules.
- La journalisation de débogage ou de suivi a été laissée activée.