Nginx worker_connections"define o número máximo de conexões simultâneas que podem ser abertas por um processo de trabalho. Esse número inclui todas as conexões (por exemplo, conexões com servidores com proxy, entre outros), não apenas conexões com clientes. Outra consideração é que o número real de conexões simultâneas não pode exceder o limite atual do número máximo de arquivos abertos ". Eu tenho poucas consultas em torno disso:

1. Qual deve ser o valor ideal ou recomendado para isso?
2. Quais são as desvantagens de usar um número alto de conexões de trabalhadores?

Vamos adotar a abordagem pragmática.

Todos esses limites são codificados e projetados no século passado, quando o hardware era lento e caro. Estamos em 2016 agora, uma torradeira wall-mart média pode processar mais solicitações que os valores padrão.

As configurações padrão são realmente perigosas. Ter centenas de usuários em um site não é nada impressionante.

worker_process

Uma configuração relacionada, vamos explicar enquanto estamos no tópico.

nginx como balanceador de carga:

• 1 trabalhador para balanceamento de carga HTTP.
• 1 trabalhador por núcleo para balanceamento de carga HTTPS.

nginx como servidores da web:

Este é complicado.

Alguns aplicativos / estruturas / middleware (por exemplo, php-fpm) são executados fora do nginx. Nesse caso, um trabalhador nginx é suficiente porque geralmente é o aplicativo externo que realiza o processamento pesado e consome os recursos.

Além disso, alguns aplicativos / estruturas / middleware podem processar apenas uma solicitação de cada vez e é uma sobrecarga para sobrecarregá-las.

De um modo geral, 1 trabalhador é sempre uma aposta segura.

Caso contrário, você poderá colocar um trabalhador por núcleo se souber o que está fazendo. Eu consideraria essa rota uma otimização e recomendaria testes e benchmarking adequados.

worker_connections

A quantidade total de conexões é worker_process * worker_connections. Metade no modo balanceador de carga.

Agora estamos chegando à parte da torradeira. Existem muitos limites de sistema seriamente subestimados:

• ulimits tem no máximo 1k de arquivos abertos por processo no linux (1k no disco, 4k no disco em alguma distribuição)
• limites systemd é quase o mesmo que ulimits.
• O padrão nginx é 512 conexões por trabalhador.
• Pode haver mais: SELinux, sysctl, supervisord (cada distro + versão é um pouco diferente)

1k worker_connections

O padrão seguro é colocar 1k em qualquer lugar.

É alto o suficiente para ser mais do que a maioria dos sites internos e desconhecidos jamais encontrará. É baixo o suficiente para não atingir outros limites do sistema.

10k worker_connections

É muito comum ter milhares de clientes, especialmente para um site público. Parei de contar a quantidade de sites que eu vi cair devido aos baixos padrões.

O mínimo aceitável para produção é 10k. Os limites do sistema relacionados devem ser aumentados para permitir isso.

Não existe um limite muito alto (um limite simplesmente não tem efeito se não houver usuários). No entanto, um limite muito baixo é algo muito real que resulta em usuários rejeitados e em um site morto.

Mais de 10k

10k é agradável e fácil.

Poderíamos definir limites arbitrários de 1000kk (afinal, é apenas um limite), mas isso não faz muito sentido prático, nunca obtemos esse tráfego e não conseguimos aceitá-lo.

Vamos manter 10k como uma configuração razoável. Os serviços que estão buscando (e podem realmente fazer) mais exigirão ajuste e benchmarking especiais.

Cenário Especial: Uso Avançado

Às vezes, sabemos que o servidor não tem muitos recursos e esperamos picos que não podemos fazer muito. Preferimos recusar usuários do que tentar. Nesse caso, coloque um limite de conexão razoável e configure boas mensagens de erro e manuseio.

Às vezes, os servidores back-end estão funcionando bem e bem, mas apenas com alguma carga , mais alguma coisa e tudo vai para o sul rapidamente. Preferimos desacelerar a travar os servidores. Nesse caso, configure a fila com limites estritos, deixe o nginx armazenar em buffer todo o calor enquanto as solicitações estão sendo drenadas em um ritmo limitado.

ulimit -a informará quantos arquivos abertos seu sistema permite que um processo use.

Além disso, net.ipv4.ip_local_port_rangedefine o intervalo total de soquetes a serem ativados por IP.

Portanto, você worker_connectionsnão pode ser mais do que qualquer um desses, ou as conexões do cliente permanecerão na fila até net.core.netdev_max_backlog- o tamanho total da fila TCP.

Lembre-se de que, se você estiver usando o nginx como proxy reverso, ele usa dois soquetes por conexão. Você pode querer brincar um pouco com net.ipv4.tcp_fin_timeoutoutros tempos limite relacionados ao tcp do kernel para tentar mudar o estado dos soquetes rapidamente. Outro ponto a ser observado é que cada soquete aloca memória da pilha de memória TCP, você também pode definir alguns limites da pilha de memória TCP sysctl, pode colocar mais pressão na RAM, desde que tenha CPU e manipuladores de arquivos suficientes.

Para sua informação, é possível, dados os recursos computacionais suficientes, ter um servidor com cerca de 32 GB de RAM e algumas interfaces de rede virtual para lidar com conexões simultâneas de 1MM com algum ajuste do kernel usando sysctl. Durante meus testes ao lidar com mais de 1MM e enviar uma carga útil de cerca de 700Bytes, o servidor estava demorando cerca de 10 segundos para atualizar cerca de 1,2MM de clientes simultâneos. O próximo passo foi aumentar a largura de banda da rede conectando algumas NICs extras e descartando as virtuais. É possível obter comunicação pseudo quase em tempo real com mais de 1,2 milhões de clientes, considerando a carga útil, a largura de banda e o tempo razoável para atualizar todos os clientes.

Afinação feliz!

O dimensionamento apropriado pode ser descoberto através de testes, pois é variável com base no tipo de tráfego que o Nginx está manipulando.

Teoricamente, o nginx pode lidar com: max clients = worker_processes * worker_connections (* = multiply) e worker_processes = número de processadores

Para descobrir os processadores, use: grep processor / proc / cpuinfo | wc -l

Definir limites mais baixos pode ser útil quando você pode ter recursos limitados. Algumas conexões, por exemplo, conexões keep-alive (não apenas com os clientes, mas também com os servidores upstream ), estão desperdiçando efetivamente seus recursos (mesmo que o nginx seja muito eficiente, o que é) e não são necessárias para a operação correta de um servidor de uso geral, o que significa que eles podem ser descartados com segurança para disponibilizar mais recursos para o restante da operação.

Ter um limite de recursos mais baixo indicaria ao nginx que você pode ter poucos recursos físicos, e os disponíveis devem ser alocados para novas conexões, em vez de servir as conexões de manutenção de vida ociosa às custas de conexões mais novas com problemas para estabelecer-se para atender às necessidades mais prementes.

Qual é o valor recomendado? É o padrão.

Os padrões estão todos documentados na documentação:

Padrão: worker_connections 512;

E pode ser confirmado a nível de código-fonte emevent/ngx_event.c também

13 # define DEFAULT_CONNECTIONS 512

A resposta de Marcel realmente precisa ser votada! Se ulimits forem configurados com um valor padrão de cerca de 1k, max_connections deve ser configurado com o mesmo valor, caso contrário, não há benefício em definir max_connections como 10k.

Você receberá a solicitação e os soquetes enfileirados no nginx se "suas conexões de trabalho não puderem ser mais do que nenhuma delas ou suas conexões de clientes ficarão em fila até net.core.netdev_max_backlog - o tamanho total da fila TCP".

Um único processo pode ser aberto, assim como a conexão, conforme permitido pelos ulimits. num_workers * max_connections é a fórmula, mas as conexões e ulimits máximos do loadbalancer / proxy precisam ser levados em consideração para obter valores razoáveis. Definir max_connection com um valor realmente alto pode sair pela culatra, pois os ulimits serão um fator limitante.