☰

Pipe-Viewerで速度制限を変更する問題

tag-icon • tag-icon linux pv
Pipe-Viewerで速度制限を変更する問題

私は経由pvでファイルを送信するために使用しますssh。

問題なく「アクティブpv」制限を100M未満に変更できます。アクティブプロセスを100Mまたは1G以上に設定すると、pv速度を変更できなくなります。

しかし！ 1Mから2Mを5～10回変更すると、2Mから1Mがpv新しい速度に設定されることがあります。

この問題の解決策が見つかりません。どんなアイデアがありますか？

例:

pv -R "15778"  -f -F "%p***%t***%e***%r***%b" -L 1M  
pv -R "15778"  -f -F "%p***%t***%e***%r***%b" -L 1G  
pv -R "15778"  -f -F "%p***%t***%e***%r***%b" -L 1M (not working anymore)

答え1

これは会計によって引き起こされpv、これは速度制限が書き込み制限ではなく読み取り制限であることを効果的に意味します。見ているソースコード比率制限が「目標」、すなわち金額によって決定されることを示します。残り送る。速度制限が有効になっている場合、速度制限評価サイクルごとに、ターゲットは速度制限に従って送信する必要がある量を増やし、実際に記録される量を減らします。つまり、レート制限を実際の書き込み容量より大きい値に設定すると、目標は増加し続けます。レート制限を下げるpvと、目標に達するまで効果はありません（新しいレートで書き込みが許可される容量を含む）。限界）。

これが実際に機能していることを確認するには、基本を実行してくださいpv。

pv /dev/zero /dev/null

次に、以下を制御します。

pv -R 32605 -L 1M; sleep 10; pv -R 32605 -L 1G; sleep 1; pv -R 32605 -L 1M

2番目の睡眠時間を変更すると、目標計算の影響を確認できます。

書き込み制限が速度​​制限を書き込み容量より大きい値に設定した場合にのみ問題が発生します。

より詳細には、400Mを送信できる接続では、トラフィックが最初に1Mに制限され、5秒間1Gに制限され、再び1Mに制限された場合にトラフィックが請求される方法は次のとおりです。

Time    Rate     Target Sent    Remaining
1       1M       1M     1M      0
2       1G       1G     400M    600M
3       1G       1.6G   400M    1.2G
4       1G       2.2G   400M    1.8G
5       1G       2.8G   400M    2.4G
6       1G       3.4G   400M    3G
7       1M       3001M  400M    2601M
8       1M       2602M  400M    2202M
9       1M       2203M  400M    1803M
10      1M       1804M  400M    1404M
11      1M       1405M  400M    1005M
12      1M       1006M  400M    606M
13      1M       607M   400M    207M
14      1M       208M   208M    0
15      1M       1M     1M      0

速度制限の再適用には7秒かかります。高い割合制限が長くなるにつれて、減少した割合制限を適用するのに時間がかかります。

この問題に対する解決策は非常に簡単です。pvで再コンパイルできる場合は、loop.c154行をtarget =（from target +=）に変更すると、結果は次のようになります。

                   || (cur_time.tv_sec == next_ratecheck.tv_sec
                       && cur_time.tv_usec >=
                       next_ratecheck.tv_usec)) {
                       target =
                           ((long double) (state->rate_limit)) /
                           (long double) (1000000 /
                                          RATE_GRANULARITY);

完了すると、レート制限の減少がすぐに適用されます（まあ、1つのレート制限期間内）。

答え2

バッファリングの問題のようです。これは私のテストベンチです。

pv --pidfile /tmp/pv.pid --rate-limit 1K </dev/zero |
    ssh remote 'cat>/dev/null'

私のコントロールは次のとおりです。

pv --rate-limit 100M --remote $(cat /tmp/pv.pid)
sleep 1
pv --rate-limit 1K --remote $(cat /tmp/pv.pid)

間隔が1秒であれば、試したpv100MB/s（1Gb/s）から最終目標である1KB/sまで降りるのに約13秒かかります。間隔をsleep1秒増やすと、最終目標を達成するのにかかる時間がほぼ10秒増えます。

Sleep   Delay
 1       13
 2       22
 3       28
 4       37

4つのサンプルはトレンドラインに十分ではないため、線形的に関連していることを示唆してはいけません。

答え3

私は自分で修正していますが、pvはスピードを変えることができます。 。
5G - 5分
10G - 7分

たとえば、

注文する:

pv --pidfile /tmp/pv.pid --rate-limit 10G </dev/zero | ssh 10.1.1.5 'cat>/dev/null'
pv --rate-limit 1M --remote $(cat /tmp/pv.pid)

-ON 10Gb/sネットワークカード:

3.99GiB 0:02:26 [ 157MiB/s] (Right here i just changed to 1M)
26.1GiB 0:02:30 [ 160MiB/s]
77.6GiB 0:09:38 [1.01MiB/s]

7分でようやく速度が変わりました。

-ON 1Gb/sネットワークカード:

10G制限を再開しました。

770MiB 0:00:07 [ 112MiB/s]
44.5GiB 0:06:49 [ 111MiB/s]
46.4GiB 0:07:31 [1.00MiB/s]

結果は同じです。 10Gから1Mに速度を変更すると、少なくとも7分待つ必要があります。しかし、1Mから10Gに速度を変更すると、待つ必要はありません。 7分（45Gb）がバッファに比べて大きすぎる必要があるため、これは単にバッファ関連であるとは思いません。しかし、それは私の意見だけです。

関連情報