28 votos

¿Necesita aumentar rendimiento nginx a un ascendente socket unix--linux kernel tuning?

Estoy corriendo un servidor nginx que actúa como un proxy para una aguas arriba de un socket de unix, como este:

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;
        }
}

Algunas servidor de la aplicación de los procesos, a su vez, tire de las solicitudes de descuento /tmp/app.sock a medida que estén disponibles. La particular del servidor de aplicaciones en uso aquí Unicornio, pero no creo que sea relevante a esta pregunta.

La cuestión es, simplemente parece que el pasado de una cierta cantidad de carga, nginx no pueden obtener las solicitudes a través de la toma de corriente, en una velocidad lo suficientemente rápida. No importa cuántas aplicación de procesos de servidor que creó.

Estoy recibiendo una avalancha de estos mensajes en el nginx registro de error:

connect() to unix:/tmp/app.sock failed (11: Resource temporarily unavailable) while connecting to upstream

Muchas peticiones resultado en código de estado 502, y aquellos que no toman mucho tiempo para completar. El nginx escribir la cola de stat se cierne alrededor de 1000.

De todos modos, me siento como que me falta algo obvio aquí, porque esta particular configuración de nginx y servidor de aplicaciones es bastante común, especialmente con Unicornio (es el método recomendado, de hecho). Hay algún kernel de linux las opciones que necesita ser establecido, o algo en nginx? Cualquier idea acerca de cómo aumentar el rendimiento de la parte de arriba de socket? Algo que claramente estoy haciendo mal?

Información adicional sobre el medio 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

Actual kernel tweaks:

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

Ulimit configuración para el nginx usuario:

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

16voto

Parece que el cuello de botella es la aplicación para alimentar la toma de corriente en lugar de ser Nginx sí mismo. Lo vemos mucho con PHP cuando se utiliza con zócalos versus una conexión TCP/IP. En nuestro caso, los cuellos de botella PHP mucho antes que Nginx jamás haría aunque.

¿Has revisado sobre el límite de seguimiento sysctl.conf conexión, límite de acumulación de zócalo

  • net.core.somaxconn
  • net.core.netdev_max_backlog

2voto

jmw Puntos 56

Podrías mirar unix_dgram_qlen , consulte la documentación de proc. ¿Aunque esto puede compuesto el problema señalando más en la cola? Tendrás que buscar (netstat - x...)

0voto

Adrian Puntos 101

Resolví aumentando el número de pedidos en el config/unicorn.rb... Yo solía tener una acumulación de 64.

 listen "/path/tmp/sockets/manager_rails.sock", backlog: 64

y me daba este error:

 2014/11/11 15:24:09 [error] 12113#0: *400 connect() to unix:/path/tmp/sockets/manager_rails.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 192.168.101.39, server: , request: "GET /welcome HTTP/1.0", upstream: "http://unix:/path/tmp/sockets/manager_rails.sock:/welcome", host: "192.168.101.93:3000"

Ahora, he aumentado a 1024 y no entiendo el error:

 listen "/path/tmp/sockets/manager_rails.sock", backlog: 1024

-1voto

valor predeterminado de atraso es 1024 en unicornio config.

http://Unicorn.BOGOMIPS.org/Unicorn/Configurator.html

listen "/path/to/.unicorn.sock", :backlog => 1024

1024 cliente es límite de sockets de dominio unix.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: