Estou executando um servidor nginx que atua como um proxy para um soquete unix upstream, assim:
upstream app_server {
server unix:/tmp/app.sock fail_timeout=0;
}
server {
listen ###.###.###.###;
server_name whatever.server;
root /web/root;
try_files $uri @app;
location @app {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app_server;
}
}
Alguns processos do servidor de aplicativos, por sua vez, retiram as solicitações /tmp/app.sock
assim que ficam disponíveis. O servidor de aplicativos específico em uso aqui é o Unicorn, mas não acho relevante para esta pergunta.
A questão é que parece que após uma certa quantidade de carga, o nginx não pode obter solicitações através do soquete a uma taxa suficientemente rápida. Não importa quantos processos do servidor de aplicativos eu configurei.
Estou recebendo uma enxurrada dessas mensagens no log de erros do nginx:
connect() to unix:/tmp/app.sock failed (11: Resource temporarily unavailable) while connecting to upstream
Muitas solicitações resultam no código de status 502 e aquelas que não demoram muito para serem concluídas. O status da fila de gravação nginx fica em torno de 1000.
De qualquer forma, sinto que estou perdendo algo óbvio aqui, porque essa configuração específica do nginx e do servidor de aplicativos é bastante comum, especialmente no Unicorn (é o método recomendado de fato). Existem opções de kernel do linux que precisam ser definidas ou algo no nginx? Alguma idéia de como aumentar a taxa de transferência para o soquete upstream? Algo que eu claramente estou fazendo errado?
Informações adicionais sobre o meio ambiente:
$ uname -a
Linux servername 2.6.35-32-server #67-Ubuntu SMP Mon Mar 5 21:13:25 UTC 2012 x86_64 GNU/Linux
$ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
$ unicorn -v
unicorn v4.3.1
$ nginx -V
nginx version: nginx/1.2.1
built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
TLS SNI support enabled
Ajustes atuais do kernel:
net.core.rmem_default = 65536
net.core.wmem_default = 65536
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_mem = 16777216 16777216 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.somaxconn = 8192
net.netfilter.nf_conntrack_max = 524288
Configurações ilimitadas para o usuário nginx:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65535
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
ulimit
, especificamente do número de arquivos abertos?ulimit -n
diz65535
.Respostas:
Parece que o gargalo é o aplicativo que liga o soquete ao invés de ser o próprio Nginx. Vemos isso muito com o PHP quando usado com soquetes versus uma conexão TCP / IP. No nosso caso, os gargalos do PHP muito mais cedo do que o Nginx jamais o faria.
Você verificou o limite de rastreamento da conexão sysctl.conf, o limite de pendências de soquete
net.core.somaxconn
net.core.netdev_max_backlog
fonte
Você pode tentar
unix_dgram_qlen
ver, consulte proc docs . Embora isso possa agravar o problema, apontando mais na fila? Você terá que procurar (netstat -x ...)fonte
Eu resolvi aumentando o número da lista de pendências no config / unicorn.rb ... Eu costumava ter uma lista de pendências de 64.
e eu estava recebendo este erro:
Agora, aumentei para 1024 e não recebi o erro:
fonte
tl; dr
listen("/var/www/unicorn.sock", backlog: 1024)
worker_connections 10000;
Discussão
Tivemos o mesmo problema - um aplicativo Rails servido pelo Unicorn atrás de um proxy reverso NGINX.
Estávamos recebendo linhas como estas no log de erros do Nginx:
Lendo as outras respostas, também descobrimos que talvez o culpado seja o Unicorn, então aumentamos a lista de pendências, mas isso não resolveu o problema. Ao monitorar os processos do servidor, era óbvio que o Unicorn não estava recebendo as solicitações para trabalhar, portanto o NGINX parecia ser o gargalo.
A pesquisa de configurações do NGINX para ajustar
nginx.conf
neste artigo de ajuste de desempenho apontou várias configurações que podem afetar o número de solicitações paralelas que o NGINX pode processar, especialmente:fonte
o valor padrão da lista de pendências é 1024 na configuração do unicórnio.
http://unicorn.bogomips.org/Unicorn/Configurator.html
O cliente 1024 é o limite de soquete de domínio unix.
fonte