35 votos

Cómo reducir el número de sockets en TIME_WAIT?

Servidor de Ubuntu 10.04.1 x86

Tengo una máquina con un FCGI servicio HTTP detrás de nginx, que sirve una gran cantidad de peticiones HTTP a un montón de diferentes clientes. (Alrededor de 230 solicitudes por segundo en las horas pico, el promedio de tamaño de respuesta con los encabezados de 650 bytes, varios millones de clientes por día.)

Como resultado, tengo un montón de enchufes, colgar en TIME_WAIT (gráfico es capturado con la configuración de TCP a continuación):

TIME_WAIT

Me gustaría reducir el número de sockets.

¿Qué puedo hacer además de este?

$ cat /proc/sys/net/ipv4/tcp_fin_timeout
1
$ cat /proc/sys/net/ipv4/tcp_tw_recycle
1
$ cat /proc/sys/net/ipv4/tcp_tw_reuse
1

Actualización: algunos detalles en el real servicio de diseño de la máquina:

cliente-----TCP socket--> nginx (equilibrador de carga de proxy inverso) 
 -----TCP socket--> nginx (trabajador) 
 --domain sockets--> fcgi-software
 --solo-persistente-TCP socket--> Redis
 --solo-persistente-TCP socket--> MySQL (otro equipo)

Yo probablemente debería cambiar de equilibrador de carga --> trabajador de la conexión de sockets de dominio así, pero la cuestión acerca de TIME_WAIT sockets seguiría siendo - I plan para agregar un segundo trabajador en una máquina separada pronto. No será capaz de utilizar sockets de dominio en ese caso.

28voto

Kyle Brandt Puntos 50907

Una cosa que usted debe hacer es empezar a solucionar el net.ipv4.tcp_fin_timeout=1. Esa es la forma en bajo, probablemente no debería tomar mucho menor que 30.

Ya que este está detrás de nginx. ¿Eso significa que nginx es que actúa como un proxy inverso? Si ese es el caso, las conexiones son 2x (uno para el cliente, uno de los servidores web). ¿Sabe usted que acabar con estas tomas que pertenece?

Actualización:
fin_timeout es el tiempo que permanecen en fin-WAIT-2 (De networking/ip-sysctl.txt en la documentación del kernel):

tcp_fin_timeout - INTEGER
        Time to hold socket in state FIN-WAIT-2, if it was closed
        by our side. Peer can be broken and never close its side,
        or even died unexpectedly. Default value is 60sec.
        Usual value used in 2.2 was 180 seconds, you may restore
        it, but remember that if your machine is even underloaded WEB server,
        you risk to overflow memory with kilotons of dead sockets,
        FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
        because they eat maximum 1.5K of memory, but they tend
        to live longer. Cf. tcp_max_orphans.

Creo que tal vez sólo tiene que dejar de Linux mantener la TIME_WAIT número de socket en contra de lo que parece tal vez 32k tapa en ellos y esto es donde Linux recicla. Este 32k se hace alusión en este enlace:

También, encontrar el /proc/sys/net/ipv4/tcp_max_tw_buckets confuso. Aunque el valor predeterminado se establece en 180000, veo un TCP interrupción cuando He 32K TIME_WAIT sockets en mi el sistema, independientemente de la max tw los cubos.

Este enlace también sugiere que el estado TIME_WAIT es de 60 segundos y no puede ser sintonizado a través de proc.

Aleatorio hecho de la diversión:
Usted puede ver los temporizadores en el timewait con netstat para cada socket con netstat -on | grep TIME_WAIT | less

La Reutilización Vs Reciclar:
Estos son una especie de interesante, que se lee como la reutilización de permitir la reutilización de time_Wait sockets, y reciclar la pone en modo TURBO:

tcp_tw_recycle - BOOLEAN
        Enable fast recycling TIME-WAIT sockets. Default value is 0.
        It should not be changed without advice/request of technical
        experts.

tcp_tw_reuse - BOOLEAN
        Allow to reuse TIME-WAIT sockets for new connections when it is
        safe from protocol viewpoint. Default value is 0.
        It should not be changed without advice/request of technical
        experts.

Yo no recomendaría el uso de la red.ipv4.tcp_tw_recycle ya que causa problemas con la NAT clientes.

Tal vez usted podría tratar de no tener tanto la de aquellos encendido y ver qué efecto tiene (Trate de uno en un tiempo y ver cómo se trabaja en su propio)? Yo usaría netstat -n | grep TIME_WAIT | wc -l más rápido a la retroalimentación de Munin.

1voto

andrew pate Puntos 26

tcp_tw_reuse es relativamente seguro, ya que permite TIME_WAIT conexiones para ser reutilizados.

También puede ejecutar más de los servicios de escucha en los diferentes puertos de detrás de su equilibrador de carga si se ejecuta fuera de los puertos es un problema.

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: