Method / Tools para analisar temporariamente o colapso da banda

5

Eu testei meu servidor¹ com uma porta de mecanização python - multi-mecanizar . Fiz vários testes bastante simples - mas sempre recebo uma queda de 10mbits para algum kb de upload de banda. E não tenho ideia do porquê.

Se eu corro 3,15 ou 30 minutos não faz diferença para o resultado. Existe sempre uma queda de banda para quase zero entre 110 e 120s, como você pode ver na análise abaixo. Eu escolhi uma corrida curta, então é mais fácil identificar a queda.

Uma verificação de htop não mostra nada especial, os núcleos estão entre 2 e 7%.
o uso da memória é sempre em torno de 1000mb (+ -100) de 2048mb de memória garantida.

Quando eu verifico iftop não há nada de especial, mas uma queda de upload de 10mbits para alguns kilobytes por ~ 10 segundos (110-120s)

Todos os trabalhos cronometrados / desnecessários estão desativados. Todas as páginas (frente / aleatória) estão disponíveis. Cada solicitação é respondida por um código de resposta http 200. Os logs de erro do Apache e do MySQL estão vazios.

Como sou um administrador que está aprendendo fazendo, não tenho certeza se existem informações mais relevantes. Os mods do apache carregados são relevantes? Espero ter mencionado todos os fatos importantes.

config.cfg

[global]
run_time = 180
rampup = 0
results_ts_interval = 10
progress_bar = on
console_logging = off
xml_report = off


[user_group-1]
threads = 10
script = frontpage.py

[user_group-2]
threads = 10
script = randompost.py

frontpage.py

import mechanize

class Transaction(object):
    def run(self):
        br = mechanize.Browser()
        br.set_handle_robots(False)

        resp = br.open('http://host.domain.tld/')
        resp.read()

        assert (resp.code == 200), 'Bad Response: HTTP %s' % resp.code
        assert ('Example Web Page' in resp.get_data())

randompost.py

na verdade o mesmo que o frontpage, mas com páginas aleatórias

import mechanize
import random

pages = [
'...',
'...',
'...',
# ...
]

class Transaction(object):
    def run(self):
        br = mechanize.Browser()
        br.set_handle_robots(False)

        resp = br.open(random.choice(pages))
        resp.read()

        assert (resp.code == 200), 'Bad Response: HTTP %s' % resp.code
        assert ('Example Web Page' in resp.get_data())




Quais ferramentas / métodos eu posso usar para diminuir a causa dessa calha?


Atualizar

Como @linuxdevops mencionado, eu tentei baixar arquivos com scp e ftp. Meus testes incluíram um arquivo de 10MB e a pasta do meu site - significa muitos arquivos de 1-1xx kb. Não houve abandono da transferência ou qualquer atraso . Não tenho certeza se existem maneiras mais profissionais de determinar a consistência de uma transferência por FTP / SCP.

¹ especificações do vhost

  • 3 vcores a 1,5 giga
  • 2048 mb ram (garantido, sem memória RAM dinâmica)
  • largura de banda de 100 mbit
  • centos 6,5 32bit
  • apache 2.2.15
por Lucas 29.04.2014 / 23:56

1 resposta

1

Um bom lugar para começar é com uma ferramenta como netperf. Google para encontrá-lo

  • Inicie o binário netserver no seu vhost
  • Do seu cliente, execute netperf: netperf -H <serverIP> -f M -l 240 -- -s 4194304

    • -f M (mostra saída em MB / s)
    • -l (comprimento em segundos)
    • -- (as opções seguem os dois traços)
    • -s (tamanho do soquete)

Esta é uma maneira fácil de encontrar o tamanho de soquete / buffer correto. Por exemplo, o tamanho de soquete padrão no Windows é apenas 8192. Uma cópia usando arrastar e soltar usará esse tamanho padrão e você aumentará em torno de 22 MB / s. Depois de aumentar para 64k, você começará a ver seus 100-120 MB / s. A maioria dos softwares nos dias de hoje permite que você altere isso ou codificará seu ponto ideal testado. Portanto, se estiver usando o winscp, ou o filezilla ou qualquer outro utilitário para essas transferências de arquivos, você deverá verificar seus buffers TCP no Linux e seus buffers do winsock no Windows.

Exemplo do Linux: /etc/sysctl.conf

  • net.ipv4.tcp_rmem = 4194304 4194304 4194304
  • net.ipv4.tcp_wmem = 4194304 4194304 4194304

Windows: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters

  • DefaultReceiveWindow = 65536
  • DefaultSendWindow = 65536

Reinicie

Se você pode rodar o netperf por mais de 120 segundos e não ver o seu vale, mas copiar os dados reais para o disco e ainda vê-lo, então você pode passar para a resolução de problemas do seu disco. Se você tentar vários tamanhos de buffer / soquete e ainda ver a diminuição, meu próximo passo seria uma captura de pacotes.

No vhost:

  1. tcpdump -i <interface> -vvv -nn -s0 port 12865 -w /desiredDir/troughTest.cap
  2. netserver
  3. Do cliente: netperf -H <serverIP> -f M -l 300 -- -s 4194304

Deixe isso funcionar por um tempo e depois ctrl-c ou mate-o quando achar que tem pacotes suficientes. Por último, ctrl-c seu tcpdump, transfira seu arquivo /diret/troughTest.cap para seu laptop / estação de trabalho, instale o wireshark se você ainda não o fez, analise pacotes

    
por 23.05.2014 / 05:14