оптимизировать извлечение текста из большого набора данных

Question

У меня есть повторяющаяся проблема, когда мне нужно искать файлы журналов для всех потоков, соответствующих шаблону. например следующее

 
(thread a) blah blah 
(thread b) blha 
(thread a) match blah 
(thread c) blah blah 
(thread d) blah match 
(thread a) xxx 

будет производить все строки из нитей & д

Есть несколько файлов журналов (сжатый). Несколько - сотни или тысячи. Каждый файл до ~ 20 МБ несжатый.

То, как я делаю это сейчас, - это первое совпадение grep во всех файлах, вырезать (thread x) часть в файл sort/uniq, а затем использовать fgrep в файле с соответствующими потоками в исходном наборе журналов ,

Я уже распараллеливаю начальный grep и окончательный grep. Однако это все еще медленно.

Есть ли способ улучшить производительность этой рабочей нагрузки? (я, хотя hadoop, но требует слишком много ресурсов для установки/реализации)

Это сценарий для всего процесса.

 

    #!/bin/bash 
    FILE=/tmp/thg.$$ 
    PAT=$1 
    shift 
    trap "rm -f $FILE" 3 13 
    pargrep "$PAT" $@ | awk '{ print $6 }' | sed 's/(\(.*\)):/\1/' | sort | uniq >$FILE 
    pargrep --fgrep $FILE $@ 
    rm -f $FILE 

Параллельная Grep гораздо больше скрипт, который управляет очередью до процессов Grep N, которые работают с файлами М. Каждый процесс grep создает промежуточный файл (в/dev/shm или/tmp - некоторую файловую систему памяти), которые затем объединяются, когда очередь стекает из задач.

Мне пришлось перезагрузить мою рабочую станцию ​​сегодня после того, как она работала на множестве ~ 3000 файлов более 24 часов. Я думаю, Dual Xeon с 8 Гб и 16 Гб свопа не до такой нагрузки :-)

Answer 1

Обновлено

Для того, чтобы распаковать и Grep файлы параллельно, попробуйте использовать GNU Parallel что-то вроде этого:

parallel -j 8 -k --eta 'gzcat {} | grep something ' ::: *.gz 

Оригинал ответа

Mmmmmm ... Я вижу, что вы не получаете никаких ответов, так что я буду придерживаться моей шеи, и попробовать. Я не тестировал это, так как у меня не так много запасных ГБ ваших данных, лежащих вокруг ...

Во-первых, я бы оценил сценарии и посмотрел, что есть время. В конкретном смысле это начальная фаза grep или фаза awk|sed|sort|uniq?

Я бы удалил sort|uniq, потому что я подозреваю, что сортировка нескольких GB съест ваше время. Если это так, то, возможно, попробуйте заменить sort|uniq с awk, как это:

pargrep ... | ... | awk '!seen[$0]++' 

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

В противном случае, я думаю, вам нужно сравнить время для различных фаз и отчитаться. Кроме того, вы должны рассмотреть возможность размещения вашего кода pargrep, поскольку это может быть узким местом. Кроме того, рассмотрели ли вы использование GNU Parallel для этой части?