我正在尝试使用64位CentOS 6将超高速数据从一个应用程序传输到另一个应用程序。我使用dd完成了以下基准测试，发现管道阻碍了我，而不是程序中的算法。我的目标是达到1.5 GB / s左右的速度。
首先，没有管道：
dd if=/dev/zero of=/dev/null bs=8M count=1000
1000+0 records in
1000+0 records out
8388608000 bytes (8.4 GB) copied, 0.41925 s, 20.0 GB/s
接下来，是两个dd进程之间的管道：
dd if=/dev/zero bs=8M count=1000 | dd of=/dev/null bs=8M
1000+0 records in
1000+0 records out
8388608000 bytes (8.4 GB) copied, 9.39205 s, 893 MB/s
我是否可以对内核进行任何调整，或进行其他任何改善通过管道运行数据的性能的调整？我也尝试过命名管道，并获得了类似的结果。
您是否尝试过使用较小的积木？
[当我在自己的工作站上尝试时，我在减小模块大小时注意到了连续的改进。在我的测试中，它仅占10％的范围，但仍是一个进步。您正在寻找100％。
事实证明，要进行进一步的测试，实际上很小的块大小似乎可以解决问题：
我尝试过
dd if=/dev/zero bs=32k count=256000 | dd of=/dev/null bs=32k
256000+0 records in
256000+0 records out
256000+0 records in
256000+0 records out
8388608000 bytes (8.4 GB) copied8388608000 bytes (8.4 GB) copied, 1.67965 s, 5.0 GB/s
, 1.68052 s, 5.0 GB/s
以及您的原始作品
dd if=/dev/zero bs=8M count=1000 | dd of=/dev/null bs=8M
1000+0 records in
1000+0 records out
1000+0 records in
1000+0 records out
8388608000 bytes (8.4 GB) copied8388608000 bytes (8.4 GB) copied, 6.25782 s, 1.3 GB/s
, 6.25203 s, 1.3 GB/s
5.0 / 1.3 = 3.8，因此是一个相当大的因素。
[看来，Linux管道一次只能向读者产生4096字节，而不管作者的写入量有多大。
因此，每个write（2）系统调用尝试将超过4096个字节填充到已填充的管道中，只会导致写入器停顿，直到读取器可以调用所需的多次读取以将大量数据从管道中拉出并执行考虑要执行的任何处理。
这告诉我，在多核或多线程CPU上（有人仍在制造单核，单线程，CPU吗？），通过使每个写入器仅在管道中，可以获得更多的并行度，从而缩短了经过的时钟时间。一次写入4096字节，然后再返回到可以进行下一个4096块的数据处理或生产。