質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.48%
Linux

Linuxは、Unixをベースにして開発されたオペレーティングシステムです。日本では「リナックス」と呼ばれています。 主にWebサーバやDNSサーバ、イントラネットなどのサーバ用OSとして利用されています。 上位500のスーパーコンピュータの90%以上はLinuxを使用しています。 携帯端末用のプラットフォームAndroidは、Linuxカーネル上に構築されています。

シェル

シェル(shell)はUnix や Linux 系のOSで使用されるコマンドインタプリタを指します。

Q&A

4回答

2670閲覧

Zcatの読み込みからfgrepで抽出をする処理を速くしたい。

nozomu0321

総合スコア18

Linux

Linuxは、Unixをベースにして開発されたオペレーティングシステムです。日本では「リナックス」と呼ばれています。 主にWebサーバやDNSサーバ、イントラネットなどのサーバ用OSとして利用されています。 上位500のスーパーコンピュータの90%以上はLinuxを使用しています。 携帯端末用のプラットフォームAndroidは、Linuxカーネル上に構築されています。

シェル

シェル(shell)はUnix や Linux 系のOSで使用されるコマンドインタプリタを指します。

0グッド

0クリップ

投稿2020/08/07 05:24

編集2020/08/07 05:29

検索処理が遅くて困ってます。
大きいログファイルから特定の行を抜き出す処理を行っててそれが数時間レベルで時間がかかってしまってます。

Lookコマンドがものすごく速いと聞いたのですが、
Lookコマンドは指定文字列から始まることが条件になっており、自分が指定したい条件は中盤に出てきます。

一応列の場所的には一意なのでawkの合わせ技で行けそうな気がしなくもないですが
なんとなく思うだけで実際どうするかが思いつきません。

Lookコマンドが必須な訳では無いです。
現状はzcatで読み込んだ後にfgrepで抽出してますが、
それならこっちの方が速いよ。とかあればお知恵を借りたいです。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Daregada

2020/08/07 05:58

「大きいログファイル」のおおまかな大きさの目安を書いてください。 検索に時間がかかっているのか、圧縮されたログファイルを展開するのに時間がかかっているのか(おそらくこっち)。
nozomu0321

2020/08/07 12:02 編集

日によって変動はありますが、圧縮された状態で500MB程度のファイルとなります。 …いや、1GBぐらい…?すみません、ちょっと記憶にしかないのですが でも絶対そのあたりの範囲です。
dameo

2020/08/07 12:01 編集

Daregadaさんのおっしゃるとおり、ファイル読み取りに時間がかかっているのか、伸長に時間がかかっているのか、検索に時間がかかっているのか?によりアプローチが違うと思います。 zcat ファイル名 | fgrep 'hoge' のような形なら \time -v zcat ファイル名 2>zcattime.log | \time -v fgrep 'hogehoge' 2>fgreptime.log のような感じで双方の時間が測れるかと思うので、本当に早くしたいなら書いておくべきだと思います。またzcatもgzip形式なのかcompress形式なのかで対策も違うと思うので、それらも正確に書いた方がいいかと思います。
nozomu0321

2020/08/07 12:04 編集

ありがとうございます。早速その形で検証して、ボトルネックの調査を進めたいと思います! なお圧縮についてはgzip形式です。
dameo

2020/08/07 12:13 編集

念の為可能なら測る前にキャッシュのクリアもしておいてください。 sudo sh -c "sync; echo 1 > /proc/sys/vm/drop_caches"
dameo

2020/08/07 12:17 編集

ただ、1GBというオーダーで数時間は遅すぎますね。どういうデバイス/メディアから読んでますか?
Daregada

2020/08/07 12:30

えっ、1GBオーダーなの? 想像していたサイズと違う。
nozomu0321

2020/08/07 12:51

ログが増えていってて、 作成済の日付の確認でfindとかも行ってるのでそれも原因かもしれません…。
dameo

2020/08/07 13:12 編集

そうなるとどこで時間がかかっているのか諸々よく分からなくなりますね。。。 デバイス/メディアの件も分からないままですし。 まずはどの処理が遅いのかちゃんと特定してください。 もし処理をシェルスクリプトでやっているのであれば、以下の1行を時間かかりそうな処理の前後に挟むと分かると思います。 echo -n "$LINENO: "; date この行を実行すると、標準出力に、 [行番号]: 2020年 8月 7日 金曜日 22:11:19 JST のような行が出てきます。 ※もし標準出力がパイプなどで繋がってたら処理が変わってしまうので、そこは気をつけてください。
Daregada

2020/08/07 13:45

とりあえずfgrepで指定している文字列と、探している行の特徴ぐらいは書こうや。ログファイルが置かれたデバイスの実態も早急に。情報を提示せずに正しい答えは得られないよ。
guest

回答4

0

なんとかならないかと、悪戦苦闘しましたが、どうにも難しいようです。
・圧縮ファイルはバイナリファイルであり、行という概念が無い。
・検索したい文字列をファイル化して圧縮しても、検索対象のファイルに同じバイト列があるとは
限らないし、同じバイト列が仮に有っても、元のテキストが一致している部分とは限らない。

なので圧縮ファイルは解凍してから通常ファイルとして取り扱うしかなく、
zcat → grep と言う手順は避け様に有りません。

いっそのこと圧縮しない運用を考えてみる方が良いのでは有りませんか。
私の業務では、圧縮する→圧縮しないに変えて劇的に処理が高速化した実例が有ります。

投稿2020/08/07 11:29

hana_yama_san

総合スコア923

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

nozomu0321

2020/08/07 12:05

貴重なお時間を割いて頂きありがとうございます。 圧縮に関してはそもそもデータが圧縮された状態で設置されるので難しそうです…。
hana_yama_san

2020/08/07 12:56

データはお客さんか委託先(ルール有り)から、通信で設置されるのでしょうね。 サイズ制限など致し方が無いですね。 ちなみに、私の愚かな悪戦苦闘の経緯は下記のようなものです。 awk 'BEGIN{ for(i=1;i<=1000;i++){ if(i % 55 == 0){print "qwertyu"}else{print "abcdefg"}}}' > zcat-grep $ gzip zcat-grep $ zcat zcat-grep.gz | awk 'NR>=40 && NR<=60{print}' abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg qwertyu abcdefg abcdefg abcdefg abcdefg abcdefg $ echo "wert" > wert && gzip wert && cat zcat-grep.gz | grep `cat wert.gz` | zcat bash: 警告: command substitution: ignored null byte in input zcat: (stdin): unexpected end of file $ cat zcat-grep.gz | od 0000000 105437 004010 031443 057455 001400 061572 072141 063455 0000020 062562 000160 150755 005073 020300 140000 156720 175133 0000040 163553 021212 157336 104123 063204 065572 030440 051345 0000060 033637 042504 146770 175332 153432 152073 077557 067720 0000100 176514 152306 046157 143375 067724 176514 152306 046157 0000120 143375 067724 176514 152306 046157 143375 067724 176514 000014 $ cat wert.gz | od 0000000 105437 004010 033472 057455 001400 062567 072162 025400 0000020 026517 160452 000002 022441 076733 000005 000000 お後が宜しい様で・・・
Daregada

2020/08/07 13:37

いやいや、zcatで読めているということは、ログファイルから無圧縮なデータを取り出せるということなんですけど。検索処理を改善するにあたって、一部のログファイルを無圧縮な状態に戻したファイルを生成し、そちらを直接grepしてみればいい。
hana_yama_san

2020/08/07 13:59

すみません。申し訳無いですが、 具体的なコマンドを書いて頂けますか。
hana_yama_san

2020/08/07 15:32

加えて申し上げますが、ファイルサイズが大きい場合 質問者さんの言う「高速化」の一番妨げになるのが zcat ではないでしょうか。 (ただのテキストのgrepなど数十万行でもどうということは無いでしょう) いかがお考えでしょうか。
Daregada

2020/08/07 21:51

先のコメントは、「質問者に」対して、「ログの生成は圧縮状態で行われるのだとしても、ボトルネックを見つけるために、圧縮を展開したファイルを用意して実験してくださいよ」という意味のアドバイスですよ。
guest

0

サイズや詳細分かりませんが、劇的に高速化したいのであればElasticsearchなどにいれるのはいかがでしょうか。

投稿2020/08/07 06:34

photographed

総合スコア10

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

nozomu0321

2020/08/07 11:48

今現状では速くしたいなーぐらいの気持ちで、 影響出てない事は無くもないんですけど、 依頼や命令というほどでもないので ソフトウェアの導入は敷居が高そうです。 ご回答頂きありがとうございました。
guest

0

一応、zgrepというコマンドもありますが、内部でそれぞれコマンドを起動しているので、速度的にはzcat ~ | grep ~~と同じでしょう。

自分が指定したい条件は中盤に出てきます。

もしカラム位置が決まっている場合(「10バイト目からABC」とか)であれば自分で検索プログラムを書くと速いかも知れませんが、egrep '^.{9}ABC'が速いかも知れません。

投稿2020/08/07 05:59

編集2020/08/07 06:34
otn

総合スコア84538

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

nozomu0321

2020/08/07 06:29

Zgrepは試して見ましたおっしゃる通りほぼ同じでした。 Grepの検索方法については単純に検索文字列の変数を指定してるだけなので、 もう少し工夫できそうなところは検討してみます。 ありがとうございました。
guest

0

【linux】ファイルの特定の範囲の行を取り出すコマンド(headとtail)
catの説明ですが、このようにheadとtailを組み合わせる事でどの辺にあるか?という事さえ分かっていれば該当行近くだけ取り出して処理が出来るかと思います。

(zcatで出すだけで我慢出来ないほど長い、となるとどうしようもありませんが。)

投稿2020/08/07 05:49

yoorwm

総合スコア1305

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

nozomu0321

2020/08/07 05:54

ご回答ありがとうございます。 特定の行というのが複数行あるんですけど、それだとダメですよね…?
yoorwm

2020/08/07 06:03

「あるコマンドの実行結果の10001行目から10100行目までが欲しいときは、これで取得できる。」とある例を使えば範囲で取れますよ。 複数ブロックあるから、という事でしたら・・・しょうがないから複数回試す、とか、必要なブロック分抽出したログファイルを作って後にgrepとか状況に合わせた工夫するしか無いと思います。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.48%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問