1) Your perl script accepts the next line of input.
2) Tcpdump refills the pipe buffer and blocks.
3) Tcpdump requests a new "line" from tcpdump_infile and transforms it .
As a consequence piping as a cheap form of using more processors does not work efficiently. It results in small read requests to the disk of one line each. The delay between the small requests starves tcpdump and your perl script. You should optimise the earliest bottleneck first.
All disks like large read requests, so the solution is to add large buffers (e. g. 100 MB each) before and after tcpdump. This allows disk reading, tcpdump and the perl script to run in parallel. I like to use mbuffer for the task. Your input pipe could look like
mbuffer -i tcpdump_infile -m 100M -P90 -p10 | \ tcpdump |\ mbuffer -m 100M -P90 -p10 | \ perl
This gives you 100 MB buffers that write ou a large chunk when 90% full and start reading again when 10% full.
In reply to Re^2: How do you parallelize STDIN for large file processing?
by NiJo
in thread How do you parallelize STDIN for large file processing?
by forsaken75
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |