優化從大型數據集提取文本

-1

我有一個反覆出現的問題，我需要爲與模式匹配的所有線程搜索日誌文件。 e.g以下優化從大型數據集提取文本

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

將生產線從所有線& d

有多個日誌文件（壓縮）。成百上千的數字。每個文件高達〜20MB未壓縮。

我現在這樣做的方式是在所有文件中首先grep「匹配」，將（線程x）部分剪切成sort/uniq文件，然後在文件上使用fgrep和原始日誌集上的匹配線程。

我已經將最初的grep和最終的grep並行化了。然而這仍然很慢。

有沒有提高此工作負載性能的方法？（我雖然hadoop，但它需要太多的資源來設置/實施）

這是整個過程的腳本。

 

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

並行grep是一個更長的腳本，它管理最多N個工作在M個文件上的grep進程的隊列。每個grep進程都會生成一箇中間文件（在/ dev/shm或/ tmp中 - 某些內存文件系統），然後在隊列從任務中消失時將其連接起來。

我在運行一組〜3000個文件超過24小時後，必須立即重啓我的工作站。我猜雙Xeon處理器和8GB掉16GB都達不到這樣的工作量:-)

來源

2014-10-05 dbbd

你如何準確地完成初始搜索？也許向我們展示你的代碼，用於各個階段... – 2014-10-05 15:53:42

更新

爲了解壓和grep並行文件，請嘗試使用GNU Parallel是這樣的：

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

原來的答案

MMMMMM ...我看到你沒有得到任何答案，所以我會堅持我的脖子，並有一個嘗試。我沒有測試過這個，因爲我的數據沒有太多的備用GB ...

首先，我會對腳本進行基準測試，看看什麼時候吃東西。具體而言，它是最初的grep階段還是awk|sed|sort|uniq階段？

我會刪除sort|uniq，因爲我懷疑排序多個GB會消耗你的時間。如果是這樣的話，也許嘗試與awk這樣更換sort|uniq：

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

這隻會它發生第一次打印每行，而不需要整個文件進行排序。

如果不這樣做，我認爲你需要對各個階段的時間進行基準測試並報告回來。此外，你應該考慮發佈你的pargrep代碼，因爲這可能是瓶頸。另外，您是否考慮過使用GNU Parallel作爲該部分？

來源

2014-10-06 09:09:04

我喜歡用awk替換sort | uniq，這很有道理。日誌文件被壓縮，所以解壓縮會消耗大量的CPU。但是，我認爲最大的問題是，有了這麼龐大的數據集，創建這麼多的中間文件並且並行處理它們會給內存帶來很大的壓力。內核開始交換，並且當交換空間被完全消耗時，我的系統停滯不前。 – dbbd 2014-10-06 13:35:57

難道你不能避免創建臨時文件的需要，現在沒有'排序' - 也許通過使用GNU並行和'-k'選項。 – 2014-10-06 14:04:05

優化從大型數據集提取文本

回答

相關問題