Shell Programming and Scripting

Assuming your input is sorted by date (which seems likely, given logfiles), processing files individually makes another really big optimization possible - once the date exceeds the cutoff, quit! You might skip entire files.

Code:

...
gunzip < "$FILE" | awk '$3 > "[20/Jun/2018:22:00:00" { exit } ; {...}' > /tmp/$$/$FNAME &
...

That may be worth trying even without multithreading, actually.

Code:

for FILE in nginx*
do
        gunzip < "$FILE" | awk '$3 > "[20/Jun/2018:22:00:00" { exit } ; {...}'
done > output

Corona688's reasoning is absolutely correct. I created a large file and timed several awk selection methods:

Code:

time awk '{if ($9 == "(200)" && $3 > "[13/Jul/2018:17:00:00" && $3 < "[13/Jul/2018:21:00:00") print}' file > /dev/null

real    0m0,794s
user    0m0,725s
sys    0m0,068s
time awk '$9 == "(200)" {if ($3 > "[13/Jul/2018:17:00:00" && $3 < "[13/Jul/2018:21:00:00") print}' file > /dev/null

real    0m0,787s
user    0m0,733s
sys    0m0,052s
time awk '$9 == "(200)" {X = substr ($3, 14); if (X > "17:00:00" && X < "21:00:00") print}' file > /dev/null

real    0m0,806s
user    0m0,732s
sys    0m0,072s
time awk '$9 == "(200)" {X = substr ($3, 14); if (X < "17:00:00") next; if (X > "21:00:00") exit; print}' file > /dev/null

real    0m0,775s
user    0m0,676s
sys    0m0,093s
time awk '$9 == "(200)" {X = substr ($3, 14); if (X ~ /1[7-9]|2[01]:[0-5][0-9]:[0-5][0-9]$/) print}' file > /dev/null

real    0m0,827s
user    0m0,727s
sys    0m0,078s

, and found very little variation in execution time. You'd better focus on the data supply / file access.

File sizes varies, for instance, some files have ~300MB, others ~1GB or ~2GB.
My disk is not operating in full capacity while running awk, so I think your solution to read multiple files at once will benefit me.

Although I can't tell what's the datetime just by file name, I can leverage the fact that log files are ordered to choose what files i'll be reading, like it was suggested here. I'll make an exampĺe to illustrate.

I have 832 files in one directory totalizing 100GB, let's say nginx1.gz, nginx2.gz, ..., nginx832.gz.
first line of nginx1.gz has [11/Jul/2018:18:00:01 and the last line [11/Jul/2018:21:00:01
first line of nginx2.gz also has [11/Jul/2018:18:00:01 and the last line [11/Jul/2018:21:00:01

The natural would be nginx2.gz start with the same time or later than nginx1.gz
I could do what you've suggested with this code:

Code:

        gunzip < "$FILE" | awk '$3 > "[20/Jun/2018:22:00:00" { exit } ; {...}'

, but I would avoid to read just 2 hours of logs. So, I thought of reading the first and last line of each file and decide whether I would read the file or not. For instance,
1st line datetime would be in: zcat file1.gz | head -n 1
last line datetime would be in: zcat file1.gz | tail -n 1

So, there are two cases when I could skip reading the files:
1 - When 1st and last line is before the time I want
2 - When 1st line is after the time I want (like you've suggested)

This way I think it'll be much faster. I've finish this modification and I'm testing it right now.
If everything is allright I'll test your solution of reading multiple files at once and give you the feedback of the results.

Thank you very much for your help, I didn't know about wait and it'll probably help me.

Unfortunately you can't seek to the end of a compressed file without decompressing the entire thing, so it really doesn't save you time. Otherwise that'd be a really good idea.

How big is your data, and how long does it take to process? These numbers will tell us how much improvement is possible worst-case.

Expanding on what Corona688 said, your two commands:

Code:

zcat file1.gz | head -n 1
zcat file1.gz | tail -n 1

decompress the file twice (maybe not completing the first decompression), and if you find that there is some data in that file that you need, you'll then decompress it again for your awk script to process.

I would strongly suggest creating a separate text file that contains the timestamp of the first record in each compressed file and the name of that compressed file. (And, add a new entry to the end of that file each time you create a new compress log file.) Then you can look at that (uncompressed) text file to quickly determine which compressed file(s) you need to uncompress and feed to your awk script to get the records you want for any particular timestamp range.

I have ~120GB of compressed files per day. It's taking many hours to process


real 217m15.559s
user 763m17.030s
sys 87m40.926s


I didn't know using tail -n 1 would descompress the entire file, but it shouldn't take less time because it doesn't compare the 3rd column of all lines? For instance, if I have 100000000 lines, it would be 100000000 comparisons that would me eliminate if the last line is before the time I want to get

The comparison is taking a trivial amount of time compared to the time required to:Anything you can do to eliminate those four steps for data that can't match your desired time range will yield huge benefits in run-time reduction.

Increasing the number of times you perform those four steps will increase your run times; not decrease them.