我在我的36核心服务器（EC2 c4.8xlarge / Amazon Linux）上运行这样的命令。
find . -type f | parallel -j 36 mycommand
要处理的文件数量是〜100万，需要几十分钟。 它应该同时运行36个进程。 但是，从top的结果来看， top只有10个进程，而70％是空闲的。 ps显示更多的进程，但其中大部分已经失效。
我猜测是因为每个mycommand如此迅速地完成， parallel无法赶上产生新的进程。 所以我尝试了parallel --nice 20来分配更多的CPU时间到parallel本身，但是这不起作用。
有没有人有一个想法来改善这一点？
$ parallel --version GNU parallel 20151022
要处理的文件数量是〜100万，需要几十分钟。
所以你每秒钟运行600个工作。 单个GNU并行作业的开销大约在2到5毫秒之间，所以当你每秒获得超过200个作业时，如果不进行调整，GNU并行将不会更好。
调整是要有更多parallel产卵工作。 从https://www.gnu.org/software/parallel/man.html#EXAMPLE:-Running-more-than-250-jobs-workaround
cat myinput | parallel --pipe -N 100 --round-robin -j50 parallel -j100 your_prg
这样你将有50个GNU并行，每个可以每秒产生100个工作。
呃，如果我理解你的问题，你想同时处理所有的文件？
parallel将启动多个mycommand实例，而不是多个find实例。
您正在尝试打开一百万个文件，每次36个。 即使你的命令可以在一个CPU上以全功率运行，你仍然会承担首先打开这些文件的开销。 I / O是计算机上耗时最多的操作之一。 最好的办法是事先将许多这些文件加载到机器的RAM中，并尽可能在RAM中工作。 取决于你有多less内存，这可能会显着提高性能，因为一旦开始读取，后续的读取往往会一个接一个地立即执行caching。 你也可能想要确保你的文件系统以caching高效的方式放置文件，而且在多个后续的读取中它是一个很好的fs。
我不认为parallel会对这个重构有很大的帮助。