GNU Parallelを効果的に使用する方法

圧縮されたテキストファイルですべての一致を検索するとします。

$ gzcat file.txt.gz | pv --rate -i 5 | grep some-pattern

pv --rateパイプのスループットを測定するためにここで使用されます。私のマシンでは、約420Mb / s（解凍後）です。

現在、GNUパラレルを使用してパラレルgrepを実行しようとしています。

$ gzcat documents.json.gz | pv --rate -i 5 | parallel --pipe -j4 --round-robin grep some-pattern

現在、スループットは〜260Mb / sに低下しています。そして、より興味深いparallelプロセス自体は、多くのCPUを使用しています。grepプロセスより多い（ただし未満gzcat）。

編集1：私はさまざまなブロックサイズ（--block）と-N/ -Lオプションのさまざまな値を試しました。この時点では何も助けになりません。

何が悪いのですか？

GNU Parallelを使用して270 MB / sに達したことに本当に驚いています--pipe。私のテストは通常​​、最大で約100 MB / sです。

あなたのボトルネックは、GNU Parallelにある可能性が最も高い--pipeです。非常に効率的ではありません。--pipepartただし、次のとおりです。ここでは、CPUコアあたり1 GB /秒のオーダーで取得できます。

残念ながら、使用にはいくつかの制限があります--pipepart。

• ファイルはシーク可能でなければなりません（つまりパイプなし）
• --recstart /-recendでレコードの先頭を見つけることができる必要があります（つまり、圧縮ファイルはありません）。
• 行番号は不明です（したがって、4行のレコードを持つことはできません）。

例：

parallel --pipepart -a bigfile --block 100M grep somepattern

grepは非常に効果的です-並列実行しても意味がありません。あなたのコマンドでは解凍だけにもっとCPUが必要ですが、これは並列化できません。

入力を並列で分割するには、grepで一致する行を取得するよりも多くのCPUが必要です。

grepの代わりに、各行にはるかに多くのCPUが必要なものを使用したい場合は、状況が変化します。並列処理の方が意味があります。

この操作を高速化したい場合-ボトルネックの場所を調べてください-おそらくそれは解凍です（他の解凍ツールまたはより良いCPUの使用に役立ちます）または-ディスクからの読み取り（他の解凍ツールまたはより良いディスクシステムの使用に役立ちます）。

私の経験から-lzma（-2など）を使用してファイルを圧縮/解凍する方が良い場合があります-gzipよりも圧縮率が高いため、ディスクから読み取る必要のあるデータがはるかに少なく、速度は同等です。

ここでの減圧がボトルネックです。解凍が内部的に並列化されていない場合、自分でそれを達成することはできません。そのようなジョブが複数ある場合は、もちろんそれらを並行して起動しますが、パイプライン自体を並列化するのは困難です。1つのストリームを並列ストリームに分割することは、それだけの価値はほとんどなく、同期とマージは非常に困難です。時々、あなたは、複数のコアがあなたが実行しているすべての単一のタスクに役立つわけではないことを受け入れる必要があるだけです。

一般に、シェルでの並列化は、ほとんどが独立したプロセスのレベルで行う必要があります。