Dê uma olhada em net.ipv4.netfilter.ip_conntrack_max sintonizável.
Para obter mais informações, leia esta postagem ServerFault
Eu tenho tentado ajustar nossas instâncias de servidor web Ubuntu 14.04 LTS, hospedando aplicativos web e nginx de proxy reverso, para lidar com o máximo possível de req / s com o hardware fornecido. É uma instância EC4 c4.2xl com 8x vCPU.
Estou executando as duas ferramentas de referência a seguir na minha máquina de escritório (NÃO ambas ao mesmo tempo):
wrk -c1000 -d2m -t8 --timeout 90 --latency http://api.mysite.com/2/ping
# or
ab -k -n 100000 -c 1000 http://api.mysite.com/2/ping
O que estou vendo é que, ao executar ss -tan | wc -l , eu sempre atingi o máximo de 65.5k conexões em TIME-WAIT
Minha configuração do sistema operacional é:
net.ipv4.ip_local_port_range value="15000 65000" /etc/security/limits.conf tem 'www-data hard nofile 100000' nele /etc/pam.d/common-session* são atualizados para ler o acima E a configuração do nginx é:
worker_processes auto; # will result in 8 on this machine
events {
worker_connections 8192;
multi_accept on;
use epoll;
}
Upstream para o api sendo proxied para nginx está abaixo, usado para obter um máximo muito alto de quadruplets TCP diferentes, o que significa que praticamente nunca ficar sem portas efêmeras em nginx - > app:
upstream my_api {
server 127.0.0.1:3004;
server 127.0.0.2:3004;
server 127.0.0.3:3004;
[...]
}
Eu tenho um problema semelhante com a minha instância m3.large, em vez de 65k no máximo em 32k. A diferença entre as duas instâncias é que a primeira tem 2vCPU, a segunda tem 8, e a primeira tem 7,5 GB de memória e a segunda tem 15 GB.
Um problema semelhante foi descrito neste post ( Escalando além de 65k arquivos abertos (Conexões TCP) ) mas parece não se aplicar no meu caso, como na minha instância menor o vm.max_map_count é 65530, mas nunca ultrapassa 32k conexões em TIME-WAIT .
Eu pensei que no início o limite era apenas # process * # workers, mas na instância menor eu ainda tinha 32k, mesmo que eu aumentasse o número de trabalhadores por processo para 25k cada, então não é isso. / p>
Não tenho certeza de qual botão girar neste ponto, não está claro para mim de onde essas restrições podem estar vindo. Poderia usar alguma ajuda aqui.
Curiosamente, não vejo conexões sendo recusadas de nenhuma dessas máquinas, pois o TIME-WAIT atinge esse "limite". É possível que as filas de soquetes estejam ocupadas nos bastidores e o cliente tente novamente estabelecer uma conexão mais tarde novamente, e é por isso que não vejo nenhuma falha permanente.
Atualização:
Em uma instância c4.8xlarge, posso obter até 262k conexões em TIME-WAIT com as mesmas configurações exatas de implantação. Mesmo limitar o número de trabalhadores nginx a apenas 1 não o altera. Ainda não tenho certeza qual seria a diferença aqui.
Atualização 2:
Suspeito que isso tenha a ver com as instâncias diferentes, todas com valores net.ipv4.tcp_max_tw_buckets diferentes, e pelo que eu sei dizer, correspondem exatamente ao padrão que estou vendo.
Dê uma olhada em net.ipv4.netfilter.ip_conntrack_max sintonizável.
Para obter mais informações, leia esta postagem ServerFault
Você está ficando sem portas de origem na sua máquina de origem.
Para identificar uma conexão que você precisa: IP de origem, porta de origem, IP de destino e porta de destino. Como o IP de Origem, o IP de Destino e a Porta de Destino são sempre os mesmos em seus testes, você tem apenas uma variável: Porta de Origem. Sua pilha TCP / IP não pode manipular mais de 64k diferentes portas de origem (na verdade, um pouco menos).
O teste de estresse a partir de um único ponto nunca é uma boa idéia, mas você pode espremer isso um pouco mais, permitindo que o net.ipv4.tcp_tw_recycle reutilize portas no status TIME_WAIT, mas isso pode causar problemas devido ao reutilização agressiva de portas.