排序--parallel不并行化

我正在尝试使用egrep -u排序从文件中拉出的唯一行，然后对其进行计数。大约有10％的行（字母表[ATCG]中的所有100个字符）重复。有两个文件，每个文件约3个演出，50％不相关，因此大约3亿行。

LC_ALL=C  grep -E  <files> |  sort --parallel=24  -u | wc -m

在LC_ALL = C和使用-x加速grep之间，到目前为止，最慢的部分是排序。阅读手册页使我走到--parallel = n，但是实验显示绝对没有任何改善。对top的一点挖掘表明，即使使用--parallel = 24，排序过程一次也只能在一个处理器上运行。

我有4个具有6个核心和2个线程/核心的芯片，总共提供48个逻辑处理器。请参阅lscpu，因为/ proc / cpuinfo将太长。

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                48
On-line CPU(s) list:   0-47
Thread(s) per core:    2
Core(s) per socket:    6
Socket(s):             4
NUMA node(s):          8
Vendor ID:             AuthenticAMD
CPU family:            21
Model:                 1
Stepping:              2
CPU MHz:               1400.000
BogoMIPS:              5199.96

我想念什么？即使进程受IO限制，我还是应该不应该看到并行处理吗？排序过程使用了它在任何给定时间实际使用的处理器的99％，因此，如果发生并行化，我应该能够看到它。内存不是问题，我有256 Gb可玩，其他任何东西都没有使用。

我发现将grep传递到文件，然后使用sort读取文件：

 LC_ALL=C  grep -E  <files>  > reads.txt ; sort reads.txt  -u | wc -m

default, file 1m 50s
--parallel=24, file 1m15s
--parallel=48, file 1m6s
--parallel=1, no file 10m53s
--parallel=2, no file 10m42s
--parallel=4 no file 10m56s

others still running

在进行这些基准测试时，很明显当管道输入排序根本不并行化时。允许读取文件时，排序将按照说明进行负载分割。

除非有必要，否则sort不会创建线程，而对于小文件而言，这只是过多的开销。现在，不幸的是sort将管道视为一个小文件。如果要向24个线程提供足够的数据，则需要指定排序以使用较大的内部缓冲区（当出现大文件时，sort会自动执行此操作）。这是我们应该在上游进行的改进（至少在文档中）。因此，您需要以下内容：

(export LC_ALL=C; grep -E  <files> | sort -S1G --parallel=24 -u | wc -m)

注意，我为所有进程都设置了LC_ALL = C，因为它们都会从这些数据中受益。

顺便说一句，您可以通过以下方式监视排序线程：

watch -n.1 ps -C sort -L -o pcpu