☰

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

두 번째 수면 시간을 변경하면 목표 계산의 영향을 확인할 수 있습니다...

쓰기 제한으로 인해 속도 제한을 쓰기 용량보다 큰 값으로 설정한 경우에만 문제가 발생합니다.

더 자세히 설명하면 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);

완료되면 비율 제한 감소가 즉시 적용됩니다(음, 하나의 비율 제한 기간 내에).

답변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초라면 pv시도한 100MB/s(1Gb/s)에서 최종 목표인 1KB/s까지 내려오는 데 약 13초가 걸립니다. 간격을 sleep1초 늘리면 최종 목표를 달성하는 데 걸리는 시간이 거의 10초 늘어납니다.

Sleep   Delay
 1       13
 2       22
 3       28
 4       37

4개의 샘플은 추세선에 충분하지 않으므로 선형적으로 관련되어 있다는 암시는 피하겠습니다.

답변3

제가 직접 수정하고 있는데 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)

-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)이 버퍼에 비해 너무 커야 하므로 이것이 단지 버퍼 관련이라고 생각하지 않습니다. 하지만 그것은 단지 내 의견일 뿐입니다.

관련 정보