Problème de Performance avec l'analyse des fichiers journaux volumineux (~5) à l'aide de awk, grep, sed

Vous avez besoin pour effectuer quelques tests pour savoir où votre goulets d'étranglement et à quelle vitesse vos différents outils d'effectuer. Essayez quelques tests de ce genre:

time fgrep '2064351200' example.log >/dev/null
time egrep '2064351200' example.log >/dev/null
time sed -e '/2064351200/!d' example.log >/dev/null
time awk '/2064351200/{print}' example.log >/dev/null

Traditionnellement, egrep devrait être le plus rapide de la bande (oui, plus vite que fgrep), mais certains les implémentations modernes sont adaptatives et de basculer automatiquement vers le bon algorithme de recherche. Si vous avez bmgrep (qui utilise le Boyer-Moore algorithme de recherche), essayez que. Généralement, sed et awk sera plus lent parce qu'ils sont conçus comme des fins plus générales de texte outils de manipulation plutôt que d'être à l'écoute pour le travail spécifique de recherche. Mais cela dépend vraiment de la mise en œuvre, et la bonne façon de le savoir est de faire des tests. Exécuter chaque plusieurs fois afin de ne pas se faire massacrer par des choses comme la mise en cache et de processus concurrents.

@Ron l'a souligné, de votre processus de recherche peut être disk I/O bound. Si vous être à la recherche du même fichier de journal d'un certain nombre de fois, il peut être plus rapide pour compresser le fichier journal de la première; cela le rend plus rapide la lecture de disque, mais alors besoin de plus de temps PROCESSEUR pour traiter, car il doit être décompressé en premier. Essayez quelque chose comme ceci:

compress -c example2.log >example2.log.Z
time zgrep '2064351200' example2.log.Z >/dev/null
gzip -c example2.log >example2.log.gz
time zgrep '2064351200' example2.log.gz >/dev/null
bzip2 -k example.log
time bzgrep '2064351200' example.log.bz2 >/dev/null

J'ai juste couru un test rapide avec une assez compressible fichier texte, et a constaté que bzip2 comprimé mieux, mais a ensuite pris beaucoup plus de temps PROCESSEUR pour décompresser, de sorte que le zgip option de liquidation être le plus rapide dans l'ensemble. Votre ordinateur sera différent de disque et les performances du PROCESSEUR que le mien, afin que vos résultats peuvent être différents. Si vous avez d'autres compresseurs qui traînent, les essayer, et/ou d'essayer les différents niveaux de la compression gzip, etc.

Parlant de prétraitement: si vous êtes à la recherche de ce même journal, est-il possible de présélectionner juste les lignes de log que vous pourrait être intéressés? Si oui, grep dans une plus petite (peut-être compressé) fichier, puis de la recherche qu'au lieu de l'ensemble de la chose. Comme avec la compression, vous passez un peu de temps supplémentaire à l'avant, mais alors, chaque individu de la recherche s'exécute plus rapidement.

Une remarque sur la tuyauterie: les autres choses étant égales par ailleurs, de la tuyauterie d'un fichier énorme à travers de multiples commandes sera plus lent que d'avoir une seule commande de faire tout le travail. Mais toutes les choses ne sont pas égaux, et si l'utilisation de plusieurs commandes dans un tuyau (qui est ce que zgrep et bzgrep ne) vous permet d'acheter une meilleure performance globale, d'aller pour elle. Aussi, demandez-vous si vous êtes réellement en passant toutes les données à travers l'ensemble de la pipe. Dans l'exemple que vous avez donné, fgrep '2064351200' example.log | fgrep 'action: example', la première fgrep jetez la plupart du fichier, la pipe et la seconde commande uniquement à traiter de la petite fraction du journal qui contient '2064351200', de sorte que le ralentissement sera probablement négligeable.

tl;dr TESTER TOUTES LES CHOSES!

EDIT: si le fichier journal est "live" (c'est à dire de nouvelles entrées sont ajoutées), mais l'essentiel est statique, vous pouvez être en mesure d'utiliser un partiel prétraiter approche: compresser (& peut-être pré-scan) le journal, puis lors de la numérisation de l'utilisation de la compression (&/prescanned) version plus une queue de la partie du journal ajoutée, puisque vous n'avez que le prescan. Quelque chose comme ceci:

# Precompress:
gzip -v -c example.log >example.log.gz
compressedsize=$(gzip -l example.log.gz | awk '{if(NR==2) print $2}')

# Search the compressed file + recent additions:
{ gzip -cdfq example.log.gz; tail -c +$compressedsize example.log; } | egrep '2064351200'

Si vous allez faire plusieurs recherches liées (par exemple, une demande particulière, puis des actions spécifiques à la demande), vous pouvez enregistrer prescanned versions:

# Prescan for a particular request (repeat for each request you'll be working with):
gzip -cdfq example.log.gz | egrep '2064351200' > prescan-2064351200.log

# Search the prescanned file + recent additions:
{ cat prescan-2064351200.log; tail -c +$compressedsize example.log | egrep '2064351200'; } | egrep 'action: example'

OriginalL'auteur Gordon Davisson

De multi-programmes en ligne sur la ligne de commande,

$ awk 'BEGIN { print "File\tOwner" }
> { print $8, "\t", \
> $3}
> END { print " - DONE -" }' infile > outfile

Notez les guillemets simples.

OriginalL'auteur hemflit