Valor ideal para Nginx worker_connections

Question

O 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 todos os conexões (por exemplo, conexões com servidores 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 no número máximo de arquivos abertos ". Eu tenho algumas dúvidas sobre isso:

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

Answer 1

Vamos dar uma abordagem pragmática.

Todos esses limites são coisas que foram codificadas e projetadas no século passado, quando o hardware era lento e caro. Estamos em 2016 agora, uma torradeira média de wall-mart pode processar mais solicitações do 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 assunto.

nginx como balanceador de carga:

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

nginx como servidores da Web:

Este é complicado.

Alguns aplicativos / frameworks / middleware (por exemplo, php-fpm) são executados fora do nginx. Nesse caso, 1 nginx worker é suficiente porque geralmente é o aplicativo externo que está processando pesado e comendo os recursos.

Além disso, alguns aplicativos / frameworks / middleware só podem processar um pedido de cada vez e ele é executado para sobrecarregá-los.

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

Caso contrário, você pode colocar um trabalhador por núcleo, se souber o que está fazendo. Eu consideraria essa rota como uma otimização e recomendaria benchmarking e testes 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 subestimados:

• ulimits é 1k max de arquivos abertos por processo no linux (1k soft, 4k hard em alguma distro)
• limites do systemd é quase o mesmo que ulimits.
• o padrão nginx é de 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 todos os lugares.

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

10k

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

O mínimo aceitável para produção é de 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 é uma coisa muito real que resulta em usuários rejeitados e em um site inativo.

Mais de 10k

10k é legal e fácil.

Poderíamos definir limites arbitrários de 1000kk (é apenas um limite, afinal de contas), mas isso não faz muito sentido prático, nós nunca conseguimos esse tráfego e não conseguimos fazer isso de qualquer maneira.

Vamos nos ater a 10k como uma configuração razoável. Os serviços que estão indo (e podem realmente fazer) mais exigirão ajustes 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 os usuários do que tentar. Nesse caso, coloque um limite de conexão razoável e configure mensagens de erro e tratamento legais.

Às vezes, os servidores de back-end estão funcionando bem e bem, mas somente até algum carregamento , nada mais e tudo vai para o sul rapidamente. Nós preferimos diminuir a velocidade do que os servidores falharem. Nesse caso, configure o enfileiramento com limites estritos, deixe o buffer nginx em todo o calor enquanto as solicitações estão sendo drenadas em um ritmo limitado.

    

Answer 2

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

Além disso, net.ipv4.ip_local_port_range define o intervalo total de soquetes para ativar por IP.

Portanto, o seu worker_connections não pode ser mais do que qualquer um deles, ou as conexões do cliente ficarão na fila até net.core.netdev_max_backlog - o tamanho total da fila TCP.

Tenha em mente que, se você estiver usando o nginx como proxy reverso, ele usará dois soquetes por conexão. Você pode querer jogar um pouco com net.ipv4.tcp_fin_timeout e outros tempos limites relacionados ao kernel tcp para tentar mudar rapidamente o estado dos sockets. Outra coisa a tomar nota é que cada soquete alocar memória da pilha de memória TCP, você também pode definir alguns limites da pilha de memória TCP usando sysctl , você pode colocar mais pressão na RAM, desde que você tenha CPU e arquivo suficiente manipuladores.

FYI é possível com recursos de computação suficientes, para 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 de kernel usando sysctl. Durante meus testes, quando lidei com mais de 1MM e enviei uma carga útil de cerca de 700Bytes, o servidor demorou cerca de 10 segundos para atualizar cerca de 1,2MM de clientes simultâneos. O próximo passo era aumentar a largura de banda da rede unindo alguns NICs extras e descartando os nics virtuais. É possível obter comunicação pseudo quase em tempo real com mais de 1.2MM clientes, considerando a carga útil, largura de banda e tempo razoável para atualizar todos os clientes.

Ajuste feliz!

    

Answer 3

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

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

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

    

Answer 4

A definição de limites inferiores pode ser útil quando você pode ser limitado por recursos. Algumas conexões, por exemplo, mantêm conexões ativas (não apenas com os clientes, mas com o servidores upstream , também estão efetivamente desperdiçando seus recursos (mesmo que o nginx seja muito eficiente, o que é), e não são necessários para a operação correta de um servidor de propósito geral, o que significa que eles podem ser seguramente caiu para disponibilizar mais recursos para o resto da operação.

Portanto, ter um limite de recursos menor indica ao nginx que você pode estar com poucos recursos físicos e que os disponíveis devem ser alocados a novas conexões, em vez de atender às conexões de manutenção ativa à custa de novas conexões com problemas sendo estabelecido para atender às necessidades mais urgentes.

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

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

Default: worker_connections 512;

E pode ser confirmado no nível do código-fonte em event/ngx_event.c , também

13#define DEFAULT_CONNECTIONS 512

    

Answer 5

A resposta de Marcel realmente precisa ser votada! Se ulimits são definidos para um valor padrão de cerca de 1k, max_connections deve ser definido em torno do mesmo valor, caso contrário, não há nenhum benefício para definir max_connections para 10k.

Você obterá solicitações enfileiradas e soquetes fechados no nginx se "suas conexões_de_servidor não puderem ser mais do que qualquer uma delas, ou suas conexões de clientes serão enfileiradas até net.core.netdev_max_backlog - o tamanho total da fila TCP."

Um único processo pode ser aberto conforme a conexão permitida pelos ulimits. num_workers * max_connections é a fórmula, mas conexões e ulimits externos do balanceador de carga / proxy devem ser levados em consideração para valores razoáveis. Configurar max_connection para um valor realmente alto pode sair pela culatra, pois ulimits serão um fator limitante.