web-dev-qa-db-ja.com

レート制限の変更に伴うパイプビューアの問題

pvを介してファイルを送信するためにsshを使用しています。

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

だが！ 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)
linuxpv
2
Morphinz

これは、pvでのアカウンティングが原因で発生します。これは、実質的に、レート制限が書き込み制限ではなく読み取り制限であることを意味します。 ソースコード を見ると、レート制限が「ターゲット」によって駆動されていることがわかります。これは、送信する残りの量です。 。レート制限がオンの場合、レート制限の評価サイクルごとに1回、レート制限に従って送信することになっている量だけターゲットが増加します。その後、実際に書き込まれた量だけターゲットが減少します。これは、レート制限を実際の書き込み容量よりも大きい値に設定すると、ターゲットが上昇し続けることを意味します。レート制限を下げても、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に制限され、次に1Gに5秒間、次に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.cで、154行目をtarget =に変更します（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つのレート制限サイクル内で）。

4
Stephen Kitt

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

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秒間隔で、実行中のpvが100MB /秒（1Gb /秒）での試行から最終目標の1KB /秒まで減少するのに約13秒かかります。 sleep間隔を1秒増やすと、最終目標を達成するまでの時間がほぼ10秒長くなります。

Sleep   Delay
 1       13
 2       22
 3       28
 4       37

トレンドラインには4つのサンプルでは十分ではないため、線形相関であると示唆することは避けます。

0
roaima

私は自分自身を修正しています。 pvは速度を変えることができます..理由はわかりませんが、制限速度に応じて少し時間がかかります... 1Gに設定した場合、速度を下げるには45秒待つ必要があります。
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)

-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分後、ようやく速度が変わりました...

-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に変更した場合、1秒待つ必要はありません。 7分（45Gb）はバッファに対して大きすぎる必要があるため、バッファだけではないと思います。しかし、これは私の意見です。

0
Morphinz