Проблемы с производительностью при разборе больших файлов журнала (~ 5 ГБ) с помощью awk, grep, sed

Question

Я сейчас занимаюсь файлами журналов с размерами ок.5gb.Я довольно плохо разбираюсь в файлах журналов и использую bash UNIX, поэтому постараюсь быть максимально точным.При поиске в файлах журнала я делаю следующее: укажите номер запроса для поиска, а затем при необходимости укажите действие в качестве вторичного фильтра.Типичная команда выглядит следующим образом:

fgrep '2064351200' example.log | fgrep 'action: example'

Это нормально для небольших файлов, но для файла журнала объемом 5 ГБ это невыносимо медленно.Я читал в Интернете, что здорово использовать sed или awk для улучшения производительности (или, возможно, даже комбинации обоих), но я не уверен, как это сделать.Например, используя awk, у меня есть типичная команда:

awk '/2064351200/ {print}' example.log

По сути, моя конечная цель - иметь возможность печатать / возвращать записи (или номер строки), которые содержат строки (может быть до 4-5, и я прочитал, что труба плохая) для эффективного сопоставления в файле журнала.

На заметку, в bash, если я хочу использовать awk и выполнить некоторую обработку, как это достигается?Например:

BEGIN { print "File\tOwner" }
{ print $8, "\t", \
$3}
END { print " - DONE -" }

Это довольно простой сценарий awk, и я предполагаю, что есть способ поместить это в команду bash с одним строком?Но я не уверен, какова структура.

Заранее спасибо за помощь.Приветствия.

Answer 1

Вам нужно выполнить несколько тестов, чтобы выяснить, где находятся ваши узкие места и как быстро работают ваши различные инструменты.Попробуйте некоторые тесты, подобные этому:

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

Традиционно egrep должен быть самым быстрым из всех (да, быстрее, чем fgrep), но некоторые современные реализации являются адаптивными и автоматически переключаются на наиболее подходящий алгоритм поиска.Если у вас есть bmgrep (который использует алгоритм поиска Бойера-Мура), попробуйте это.Как правило, sed и awk будут работать медленнее, потому что они разработаны как более универсальные инструменты для работы с текстом, а не для конкретной задачи поиска.Но это действительно зависит от реализации, и правильный способ выяснить это - запустить тесты.Запускайте их по несколько раз, чтобы не мешать таким вещам, как кеширование и конкурирующие процессы.

Как указывал @Ron, ваш процесс поиска может быть связан с дисковым вводом / выводом.Если вы будете искать один и тот же файл журнала несколько раз, сначала может быть быстрее сжать файл журнала;это ускоряет считывание с диска, но затем требует больше процессорного времени для обработки, потому что сначала его нужно распаковать.Попробуйте что-то вроде этого:

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

Я только что провел быстрый тест с довольно сжимаемым текстовым файлом и обнаружил, что bzip2 сжимается лучше всего, но затем потребовалось гораздо больше процессорного времени для распаковки, поэтому опция zgip завеласьбыть самым быстрым в целом.Ваш компьютер будет иметь другую производительность диска и процессора, чем у меня, поэтому ваши результаты могут отличаться.Если у вас есть другие компрессоры, попробуйте их и / или попробуйте разные уровни сжатия gzip и т. Д.

Кстати, о предварительной обработке: если вы просматриваете один и тот же журнал снова и снова, есть лиспособ предварительно выбрать только те строки журнала, которые вас могут заинтересовать?Если это так, сгруппируйте их в файл меньшего размера (возможно, сжатый), а затем выполните поиск вместо всего этого.Как и в случае со сжатием, вы тратите дополнительное время заранее, но затем каждый отдельный поиск выполняется быстрее.

Примечание о конвейерной обработке: при прочих равных условиях конвейер огромного файла с помощью нескольких команд будет медленнее, чем при использовании однойКоманда делает всю работу.Но все здесь не одинаково, и если использование нескольких команд в конвейере (что делают zgrep и bzgrep) повышает общую производительность, сделайте это.Кроме того, подумайте, действительно ли вы передаете все данные по всей трубе.В приведенном вами примере fgrep '2064351200' example.log | fgrep 'action: example' первый fgrep отбросит большую часть файла;pipe и вторая команда должны обрабатывать только небольшую часть журнала, содержащую «2064351200», поэтому замедление, скорее всего, будет незначительным.

tl; dr ПРОВЕРИТЬ ВСЕ ВЕЩИ!

РЕДАКТИРОВАТЬ: если файл журнала «живой» (т. е. добавляются новые записи), но основная его часть статична, вы можете использовать частичный подход предварительной обработки: сжать (и, возможно, предварительно просканировать) журнал, а затем при сканировании использоватьсжатая (& / prescanned) версия плюс хвостовая часть журнала, добавленная после предварительного сканирования.Примерно так:

# 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'

Если вы собираетесь выполнить несколько связанных поисков (например, определенный запрос, затем конкретные действия с этим запросом), вы можете сохранить предварительно отсканированные версии:

# 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'

Answer 2

Если вы не знаете последовательность ваших строк, то:

awk '/str1/ && /str2/ && /str3/ && /str4/' filename

Если вы знаете, что они появятся один за другим в строке:

grep 'str1.*str2.*str3.*str4' filename

(примечание для awk, {print} - блок действий по умолчанию, поэтому его можно опустить, если задано условие)

Работа с файлами большого размера будет медленной независимо от того, как вы ее нарезаете.

Answer 3

Что касается многострочных программ в командной строке,

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

Обратите внимание на одинарные кавычки.

Answer 4

Если вы обрабатываете один и тот же файл несколько раз, может быть быстрее прочитать его в базу данных и, возможно, даже создать индекс.