Determina os limites de carregamento do proxy reverso nginx

Question

Eu tenho um servidor nginx (CentOS 5.3, linux) que estou usando como um balanceador de carga de proxy reverso na frente dos servidores de aplicativos de 8 ruby on rails. À medida que nossa carga nesses servidores aumenta, começo a me perguntar em que ponto o servidor nginx se tornará um gargalo? As CPUs são pouco usadas, mas isso é esperado. A memória parece estar bem. Não IO de falar.

Então, é a minha única limitação de largura de banda nas NICs? Atualmente, de acordo com alguns gráficos de cactos, o servidor está atingindo cerca de 700 Kbps (média de 5 min) em cada NIC durante a carga alta. Eu acho que isso ainda é muito baixo.

Ou o limite estará em sockets ou algum outro recurso no sistema operacional?

Obrigado por quaisquer pensamentos e ideias.

Editar:
racyclist:

Obrigado pelas suas ideias. Eu fiz um pouco mais de escavação. Eu tenho 1 trabalhador permitindo 1024 worker_connections. Vamos supor que 95% das solicitações sejam para pequenas quantidades de dados. Quaisquer recomendações sobre o que um sistema com 512MB deve ser capaz de manipular, conexões sábias?

Além disso, o que é uma boa maneira de contar as conexões? Algo assim seria preciso?:

netstat -np | grep ESTABLISHED | grep nginx | wc -l

End Edit

Aaron

    

Answer 1

Atualmente, você tem carga muito baixa de acordo com a utilização da largura de banda. Há muitos possíveis afunilamentos, para citar alguns:

Relacionado à rede

À medida que o número de conexões aumenta, você pode atingir worker_connections limite de um processo de trabalho do Nginx. A descrição do racyclist é muito boa, vou adicionar alguns centavos a ele. Na verdade, quanto mais trabalhadores você tiver, mais possibilidades você poderá atingir worker_connections de um trabalhador em particular. A razão para isso é que o processo mestre do Nginx não pode garantir uma distribuição uniforme das conexões entre os trabalhadores - alguns deles podem processar pedidos mais rapidamente do que outros e, assim, o limite pode ser excedido finalmente.

Meu conselho é usar o menor número possível de funcionários com um grande número de worker_connections . No entanto, você terá que aumentar o número de trabalhadores se tiver E / S (veja mais adiante). Use o módulo status do nginx para observar o número de soquetes que ele usa.

Você provavelmente atingirá o limite do sistema operacional (Linux ou FreeBSD) no número de descritores de arquivos abertos por processo. O Nginx usará descritores não apenas para solicitações de entrada, mas também para conexões de saída para backends. Inicialmente, este limite é ajustado para o valor muito baixo (por exemplo, 1024). O Nginx irá reclamar em seu error.log sobre este evento.

Se você estiver usando iptables e seu módulo conntrack (Linux), você deve exceder o tamanho da tabela conntrack . Cuidado com dmesg ou /var/log/messages . Aumente este limite conforme necessário.

Algumas ótimas aplicações otimizadas utilizam 100% de largura de banda. Minha aposta é que você deve enfrentar problema (s) anterior (es) antes.

IO relacionado

Na verdade, um trabalhador do Nginx bloqueia o IO. Assim, se seu site estiver veiculando conteúdo estático, você precisará aumentar o número de funcionários do Nginx para contabilizar o bloqueio de E / S. É difícil dar receitas aqui, pois elas variam muito dependendo do número e tamanho dos arquivos, tipo de carga, memória disponível, etc.

Se você estiver fazendo proxy de conexões para algum back-end através do Nginx, deve levar em conta que ele cria arquivos temporários para armazenar a resposta do backend e, no caso de alto tráfego, isso pode resultar em uma carga substancial no sistema de arquivos. Observe as mensagens em error.log do Nginx e ajuste proxy_buffers (ou fastcgi_buffers ) de acordo.

Se você tiver algum IO em segundo plano (por exemplo, MySQL), ele afetará também os arquivos estáticos. Preste atenção em IO wait%

    

Answer 2

É mais do que apenas a largura de banda de uma placa de rede. O Nginx tem um número máximo de conexões que ele pode manipular. As conexões máximas podem ser representadas por uma fórmula simples: "worker_processes" * "worker_connections". O gargalo vai depender do seu aplicativo. Se você tiver muitas conexões usando pouca largura de banda, é mais provável que você fique sem conexões antes de preencher o seu pipe. Por outro lado, um pequeno número de conexões usando muita largura de banda poderia preencher o seu canal sem atingir o número máximo de conexões.

    

Answer 3

Em relação a conexões abertas. A melhor maneira de controlá-los é verificando / proc / net / ip_conntrack.

cat /proc/net/ip_conntrack | egrep 'dport=(80|443)'| wc -l 

Agora, com relação à sua pergunta sobre o nginx, não há uma resposta real. Você só precisa avaliar sua configuração (usando ferramentas como o httperf) e ver qual é a carga que você pode manipular.