Esta é provavelmente uma continuação do meu anterior (sem resposta) pergunta porque a causa subjacente é provavelmente a mesma.
Eu tenho um servidor Linux com nginx e sshd rodando nele. Está em um link unmetered de 100mbit / s compartilhado. Durante os "horários de pico" (basicamente, durante o dia nos EUA), o desempenho do sftp se torna muito ruim, às vezes o tempo limite antes que eu possa me conectar. O ssh não é afetado. Eu sei que é nginx porque quando eu paro nginx, o problema com o sftp desaparece instantaneamente. No entanto, o próprio nginx possui essencialmente latência zero durante esses "episódios".
Este é um problema de longa data com o meu servidor, e decidi recentemente resolvê-lo de uma vez por todas. Ontem eu comecei a suspeitar que o grande volume de tráfego HTTP, juntamente com a maior latência induzida pela falta de largura de banda do upstream, estava eliminando o tráfego do meu tráfego. Eu usei tc para adicionar alguma priorização:
/sbin/tc qdisc add dev eth1 root handle 1: prio
/sbin/tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip dport 22 0xffff flowid 1:1
/sbin/tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip sport 22 0xffff flowid 1:1
/sbin/tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip protocol 1 0xff flowid 1:1
Infelizmente, embora eu possa ver os pacotes sftp se acumulando no primeiro prio:
class prio 1:1 parent 1:
Sent 257065020 bytes 3548504 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class prio 1:2 parent 1:
Sent 291943287326 bytes 206538185 pkt (dropped 615, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class prio 1:3 parent 1:
Sent 22399809673 bytes 15525292 pkt (dropped 2334, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
... a latência ainda é inaceitável ao se conectar. Aqui estão alguns gráficos bonitos que fiz agora, tentando correlacionar algo com a latência do sftp:
Aquiestáalatênciadosftpdeumlocaldiferente.Eutenhootempolimitedefinidoem25segundos.Qualquercoisamaiordoqueos1-2segundosnormaisnecessáriosparaconectarebaixarumpequenoarquivoéinaceitávelparamim.Vocêpodevercomoficatudobemduranteanoiteedepoisalatênciaentraemaçãonovamenteduranteodia.
Conteúdo de /proc/net/sockstat . Observe a correlação aparente da latência do sftp com o uso da memória TCP. Não faço ideia do que isso significa.
Saídadomódulodestubdonginx.Nadaparaveraqui...
Saída de netstat -tan | awk '{print $6}' | sort | uniq -c . Mais uma vez, parece plana.
Então, por que o tc não funciona para mim? Preciso realmente limitar a largura de banda em vez de apenas priorizar a entrada e a saída da porta 22? Ou é tc a ferramenta errada para o trabalho e eu estou totalmente perdendo a verdadeira causa do mau desempenho do sftp?
Saída de uname -a :
Linux [redacted] 3.2.0-0.bpo.2-amd64 #1 SMP Fri Jun 29 20:42:29 UTC 2012 x86_64 GNU/Linux
Estou executando o nginx 1.2.2 com o módulo de streaming mp4 compilado.
Editar 2012/07/31:
ewwhite perguntou se estou perto ou no limite de largura de banda. Eu verifiquei e parece haver uma correlação (embora não perfeita) entre o limite de 100 mbit e a latência do sftp ruim:
Por que, no entanto, o tráfego sftp (associado à porta 22) não seria priorizado mais do que o tráfego HTTP durante esses episódios?
Editar 2012/07/31 # 2
Na coleta de dados de latência do sftp / scp, notei um padrão, conforme mostrado no gráfico abaixo (as linhas verdes que adicionei):
Doisclusters-subtraindoalatênciade"linha de base", eles estão em ~ 5 e ~ 10 segundos. Você também pode vê-los claramente no gráfico de latência do sftp acima em uma escala de tempo muito maior. De onde vem esse número de 5 segundos?