☰

パイプとリダイレクト速度、「pv」とUUOC

tag-icon • tag-icon pipe cat pv
パイプとリダイレクト速度、「pv」とUUOC

ランダムゴミを生成し、pv次のように出力をパイピングして速度を比較するさまざまな方法をテストしています。

$ cmd | pv -s "$size" -S > /dev/null

私はまた、「リファレンスリファレンス」が欲しかったので、cat最速のソースで最速の「ジェネレータ」を測定しました/dev/zero。

$ cat /dev/zero | pv -s 100G -S > /dev/null
 100GiB 0:00:33 [2,98GiB/s] [=============================>] 100%

3GB/秒、特に次のような場合は非常に印象的です。~70MB私はから来ました/dev/urandom。

/dev/zeroしかし、特別な場合には必要ありませんcat！ただ楽しんでこの教科書を消しました。ウルムチ大学:

$ < /dev/zero pv -s 100G -S > /dev/null
 100GiB 0:00:10 [9,98GiB/s] [=============================>] 100%

何？ ？ ？ほぼ10GB/秒？解体catとパイプラインはどのように比較されますか？三回スピード？たとえば、遅いソースを使用している場合、/dev/urandom違いは無視できます。魔法を呼ぶのでしょうかpv？だからテストしました：

$ dd if=/dev/zero iflag=count_bytes count=200G of=/dev/null status=progress
205392969728 bytes (205 GB, 191 GiB) copied, 16 s, 12,8 GB/s

12.8GB/秒！パイプを使うのとほぼ同じでpv、パイプを使うよりも4倍速いです。

あなた自身のせいですかcat？パイプはリダイレクトとは大きく異なりますか？最後に、両方ともpvasに移動しますstdin。そうですか？この大きな違いを何で説明できますか？

答え1

秘訣は、2つのプロセスを使用することです。

同じcat | pv、cat読み取りと書き込み、pv読み取りと書き込み、両方のプロセスを実行する必要があります。

$ perf stat sh -c 'cat /dev/zero | pv -s 100G -S > /dev/null'
 100GiB 0:00:26 [3.72GiB/s] [====================================================================================>] 100%            

 Performance counter stats for 'sh -c cat /dev/zero | pv -s 100G -S > /dev/null':

         34,048.63 msec task-clock                #    1.267 CPUs utilized          
         1,676,706      context-switches          #    0.049 M/sec                  
             3,678      cpu-migrations            #    0.108 K/sec                  
               304      page-faults               #    0.009 K/sec                  
   119,270,941,758      cycles                    #    3.503 GHz                      (74.89%)
   137,822,862,590      instructions              #    1.16  insn per cycle           (74.94%)
    32,379,369,104      branches                  #  950.974 M/sec                    (75.14%)
       216,658,446      branch-misses             #    0.67% of all branches          (75.04%)

      26.865741948 seconds time elapsed

       1.257950000 seconds user
      38.893870000 seconds sys

専用pv、pv読み取り、書き込みのみ可能、コンテキスト切り替えは不要（またはほとんどありません）：

$ perf stat sh -c '< /dev/zero pv -s 100G -S > /dev/null'
 100GiB 0:00:07 [13.3GiB/s] [====================================================================================>] 100%            

 Performance counter stats for 'sh -c < /dev/zero pv -s 100G -S > /dev/null':

          7,501.68 msec task-clock                #    1.000 CPUs utilized          
                37      context-switches          #    0.005 K/sec                  
                 0      cpu-migrations            #    0.000 K/sec                  
               198      page-faults               #    0.026 K/sec                  
    27,916,420,023      cycles                    #    3.721 GHz                      (75.00%)
    62,787,377,126      instructions              #    2.25  insn per cycle           (74.99%)
    15,361,951,954      branches                  # 2047.801 M/sec                    (75.03%)
        51,741,595      branch-misses             #    0.34% of all branches          (74.98%)

       7.505304560 seconds time elapsed

       1.768600000 seconds user
       5.733786000 seconds sys

いくつかの並列処理（「1.267 CPUを使用」）がありますが、コンテキスト切り替え数の大きな違いを補償するものではありません。

データパスを考慮すると、状況はおそらくはるかに悪いでしょう。最初の場合、データは/dev/zeroカーネル（）からcatカーネル（パイプの場合）に戻り、その後pvカーネル（/dev/null）に流れるように見えます。 2番目のケースでは、データはコアからコアに流れ、pv再びコアに流れます。しかし、pv最初のケースではspliceカーネル所有メモリを通過しないようにパイプからデータをコピーします。

関連情報