Início / unix / Perguntas / 419341
Accepted
Morphinz
Asked: 2018-01-25 05:10:14 +0800 CST

Problema do Pipe-Viewer com alteração do limite de taxa

  • 772

Estou usando pvpara enviar arquivos via ssh.

Posso alterar o limite de "pv ativo" para menos de 100M sem nenhum problema. Quando defino o processo ativo pvpara 100M ou 1G ou superior, não consigo mais alterar a taxa...

MAS! se eu mudar 5-10 vezes 1M para 2M, 2M para 1M pvpode ser definido às vezes para uma nova taxa.

Não consegui encontrar nenhuma solução para o problema. Qualquer ideia?

Exemplos:

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)
linux pv

3 respostas

  1. Best Answer

    Isso é causado pela contabilização em pv, o que significa efetivamente que sua limitação de taxa é limitada por leitura em vez de limitada por gravação. Observar o código-fonte mostra que a limitação de taxa é impulsionada por um “alvo”, que é a quantidade restante para enviar. Se o rate-limiting estiver ativado, uma vez por ciclo de avaliação do rate limit, o alvo é aumentado em quanto devemos enviar de acordo com o rate limit; o alvo é então diminuído por quanto é realmente escrito. Isso significa que se você definir o limite de taxa para um valor maior do que a capacidade de gravação real, o destino continuará subindo; reduzir o limite de taxa não terá nenhum efeito até pvque tenha alcançado seu objetivo (incluindo o que é permitido gravar de acordo com o novo limite de taxa).

    Para ver isso em ação, inicie um básico pv:

    pv /dev/zero /dev/null

    Então controle isso:

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

    Você verá o impacto dos cálculos de alvo variando a duração do segundo sono...

    Devido à limitação de gravação, isso só causa um problema quando você define o limite de taxa para um valor maior que a capacidade de gravação.

    Com um pouco mais de detalhes, veja como funciona a contabilidade com um fluxo inicialmente limitado a 1M, depois a 1G por 5s, depois de volta a 1M, em uma conexão capaz de transmitir 400M:

    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

    Demora 7s para que o limite de taxa seja aplicado novamente. Quanto mais tempo gasto com um limite de taxa alto, mais tempo levará para que o limite de taxa reduzida seja aplicado...

    A correção para isso é bastante direta, se você puder recompilar pv: em loop.c, altere a linha 154 para target =(de target +=), resultando em

                       || (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);

    Feito isso, as reduções do limite de taxa são aplicadas imediatamente (bem, dentro de um ciclo de limite de taxa).

    • 5

  2. Parece ser um problema de buffer. Aqui está minha cama de teste:

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

    e aqui está o meu controle:

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

    Com um intervalo de um segundo, leva cerca de 13 segundos para a execução pvreduzir de sua tentativa de 100 MB/s (1 Gb/s) para sua meta final de 1 KB/s. Aumentar o sleepintervalo em 1 segundo aumenta o tempo para atingir o objetivo final em quase 10 segundos:

    Sleep   Delay
 1       13
 2       22
 3       28
 4       37

    Quatro amostras não são suficientes para uma linha de tendência, então vou evitar sugerir que é uma correlação linear.

    • 0

  3. Estou me corrigindo; pv pode alterar a velocidade.. Não sei por que, mas precisa de algum tempo de acordo com o seu limite de velocidade... Se você definir para 1G, terá que esperar 45 segundos para reduzir a velocidade.
    5G - 5 min.
    10G - 7 min.

    Por exemplo:

    Comandos:

    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 placa de rede 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]

    Após 7 minutos a velocidade mudou finalmente...

    -ON placa de rede 1Gb/s:

    Comecei novamente com limite de 10G.

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

    Os resultados são os mesmos. Se você alterar a velocidade de 10G para 1M, precisará aguardar pelo menos 7 minutos. Mas se você alterar a velocidade de 1M para 10G, não precisará esperar nenhum segundo. Eu não acho que seja apenas com buffer porque 7min (45Gb) deve ser muito grande para o buffer. Mas esta é apenas a minha opinião.

    • 0

relate perguntas