Dans mon serveur Web (apache est en cours d'exécution, Linux CentOS), il y a un très gros fichier journal ( 50 Go ). Ce serveur Web a des services Web en production.
Lorsque j'ai essayé de supprimer le fichier journal, le serveur Web n'a reçu aucune réponse environ 10 secondes. (Temps de service.)
rm -f monthly.log
Existe-t-il un moyen de supprimer ce gros fichier sans geler Apache?
Réponses:
Faites-le pivoter d'abord via logrotate, en utilisant une configuration comme celle-ci:
/path/to/the/log {
missingok
notifempty
sharedscripts
daily
rotate 7
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
compress
}
puis créez un travail cron à minuit pour supprimer le fichier pivoté:
30 2 * * * nice -n 19 ionice -c2 -n7 rm -f /path/to/the/log/file.1
Pour une suppression plus rapide des gros fichiers, vous pouvez utiliser la truncatecommande - Dites de la réduire à une taille nulle, puis supprimez-la:
truncate -s 0 monthly.log && rm -f monthly.log
Comme l'a recommandé quanta, vous devez d'abord le faire tourner.
truncatedifférent de >?
truncateest plus facile à utiliser avec sudode >. C'est aussi plus facile avec find -exec.
echo "0" > monthly.log && rm -f monthly.log
>logfilepas avoir besoin d'écho
Je tronquerais / mettrais à zéro le fichier avec l' : > /path/to/monthly.logopération. Ensuite, redémarrez éventuellement le processus Apache et configurez la rotation des journaux pour éviter que cela ne se reproduise à l'avenir ...
Cela revient souvent, cependant:
Voir: Existe - t-il un moyen de supprimer un fichier de 100 Go sous Linux sans thrash IO / load?
:. Vous pouvez juste faire> /path/to/monthly.log
noop, mais cela a plus de sens d'un point de vue pédagogique.
true > /path/to/monthly.logla même chose, et c'est moins archaïque alors :?
Si vous n'avez pas besoin des données, tronquez-les en utilisant / dev / null:
cat /dev/null > monthly.log
Le serveur Web continuera d'écrire des données dans le fichier après la troncature, ce qui évite d'avoir à redémarrer le serveur Web (contrairement à rm monthly.logce qui supprime le fichier).
Après avoir résolu la crise immédiate, envisagez la logrotation comme l'a suggéré Quanta. Vous ne voulez pas que cela se reproduise. Notez que les fichiers journaux Apache sont déjà tournés par défaut sur CentOS
Pensez également à envoyer les journaux Web via syslog (en utilisant /usr/bin/logger, par exemple). Les journaux créés à l'aide de syslog ont également généralement déjà configuré la rotation du journal.
>logfilepas avoir besoin de chat
Si vous utilisez le système de fichiers ext3, envisagez de passer à ext4.
Ext3 peut être lent à supprimer des fichiers volumineux car il stocke l'emplacement de chaque bloc 4k individuel: un fichier de 50 Go (50 * 1024 ^ 3 octets) occupe 13107200 blocs, chacun étant enregistré dans la table d'inode sous la forme d'un numéro de bloc 32 bits , pour un total de 50 Mo de données de comptabilité juste pour garder une trace de l'emplacement du contenu du fichier sur le disque. Cette grande liste de blocs peut être dispersée sur de nombreux blocs indirects , qui doivent tous être mis à jour lorsque le fichier est supprimé. Le disque cherchant à accéder à tous ces blocs indirects est probablement à l'origine du retard.
Ext4, d'autre part, alloue des fichiers dans des «extensions» allant jusqu'à 128 Mo. Ce fichier de 50 Go peut être enregistré dans la table d'inode en utilisant seulement 400 enregistrements d'étendue, plutôt que 13107200 numéros de bloc individuels, ce qui réduit considérablement la quantité d'E / S disque nécessaires lors de la suppression du fichier.
Notez que si vous convertissez un système de fichiers ext3 existant sur place en ext4, les nouveaux fichiers seront alloués en utilisant des extensions, mais les fichiers existants utiliseront toujours des listes de blocage. Vous pouvez utiliser la chattr +ecommande pour réaffecter un fichier existant à l'aide d'extents; en termes de performances, cela revient à faire une copie du fichier, puis à supprimer l'original.
Cela se résume à un problème de performances du système de fichiers. Il y a une réponse intéressante à cette question SO mais cela dépend plutôt du système de fichiers que vous utilisez. J'ai utilisé XFS lors de la création d'un système de fichiers pour stocker des centaines de fichiers MPEG2 multi-gigaoctets pour MythTV car à l'époque les performances de suppression de XFS étaient bien supérieures à ext3. Les choses ont peut-être changé considérablement entre-temps.
J'aime bien la réponse de @ quanta. La division du fichier en parties plus petites entraînera une suppression plus rapide.
Je suppose que le problème vient du fait que vous supprimez le fichier de l'utilisateur privilégié qui a plus de priorité aux opérations sur le disque que l'utilisateur du serveur Web Apache. Quelle que soit la manière dont vous choisissez de supprimer le fichier journal (rm -f ou tronqué par>), vous devez réduire ses opérations de priorité de disque à un minimum:
ionice -c3 rm -f filename.log