Blog

Archive for Linux Networking

KB: 24032014-001: Gestionando problemas con time wait (no más conexiones TCP)

Índice de claves del artículo

Síntomas

1) Ha recibido una notificación del time_wait_checker 2) o después de una revisión, encuentra que todos los servicios están arriba y funcionando pero no pueden aceptar más conexiones (cuando deberían) o algún servicio no puede conectar a servicios internos como servidores de bases de datos (como MySQL). Al mismo tiempo, si ejecuta el siguiente comando, obtiene más de 30000 entradas:

>> netstat -n | grep TIME_WAIT | wc -l

Otro síntoma es que servidores específicos como squid fallan con el siguiente error:

commBind: Cannot bind socket FD 98 to *:0: (98) Address already in use

Revisiones afectadas

Todas las revisiones pueden sufrir este problema. No es un bug sino un problema de agotamiento de recursos.

Antecedentes

Este problema se dispara porque algún servicio está creando conexiones más rápido de lo que estas son cerradas totalmente para su reutilización. Después de que una conexión TCP es cerrada, se comienza un periodo para recibir paquetes perdidos para esa conexión, de cara a evitar mezclar estos con paquetes para nuevas conexiones creadas en la mismo localización.

Cada vez que una conexión TCP es creada, un puerto local es necesario para el extremo local. Este puerto para el extremo local es tomado del rango de puertos efímeros tal y como se define en:

/proc/sys/net/ipv4/ip_local_port_range

Si este rango es agotado, no se podrán crear más conexiones TCP porque no hay más puertos efímeros (puertos locales) disponibles.

Hay varias maneras de resolver este problema. Las siguientes soluciones se muestran en el orden de recomendación:

  1. Identificar la aplicación que está creando estas conexiones y revisar si hay algún problema.
  2. Si no es posible, incremente el rango de puertos efímeros. Vea la siguiente sección.
  3. Si incrementar el rango de puertos efímeros no soluciona el problema, intente reducir la cantidad de tiempo que una conexión pasada en estado TIME_WAIT. Vea la siguiente sección.
  4. Si esto tampoco resuelve el problema, intente activar la opción de reutilización de conexiones en TIME_WAIT lo que causará que el sistema reutilice puertos en estado TIME_WAIT. Vea la siguiente sección.

Solución

En el caso de que no pueda corregir la aplicación que produce esta cantidad de conexiones en TIME_WAIT, utilice las siguientes opciones proporcionadas por el comprobador time_wait_checker para configurar el sistema de cara a reaccionar mejor a esta situación..

  1. Primero, seleccione la máquina, y luego pulse en acciones (en la parte superior derecha de la vista de máquina):actions
  2. Ahora, pulse sobre “Mostrar comprobadores”:
  3. Ahora, seleccione el comprobar “time_wait_checker” y después pulse sobre:
    configure.
  4. Después de esto, la siguiente ventana se mostrará con varias opciones de gestión para el TIME_WAIT:
    Core-Admin Time-wait's checker options

Ahora use estas opciones disponibles tal y como se ha descrito y en el orden recomendado.

Algunas notas sobre las opciones Tcp time wait reuse and recycle

Una mención especial para la opción Tcp time wait recycle ( /proc/sys/net/ipv4/tcp_tw_recycle ) referente a que esta se considera más agresiva que la opción Tcp time wait reuse  ( /proc/sys/net/ipv4/tcp_tw_reuse ). Ambas opciones pueden causar problemas ya que aplican “simplificaciones” para reducir el “time wait” y el reusado de ciertas estructuras. En el caso de “Tcp time wait recycle”, debido a su naturaleza, puede causar problemas con los dispositivos detrás de un NAT permitiendo conexiones de manera aleatoria (solo un dispositivo será capaz de conectar al servidor con esta opción activada). Como indica la herramienta (“Observe after activation”). Más información sobre “Tcp time wait recycle” y cómo se relaciona con los dispositivos detrás de un NAT en http://troy.yort.com/improve-linux-tcp-tw-recycle-man-page-entry/

En general, ambas opciones no deberían ser usadas si no es necesario.

Soluciones a largo plazo

Las siguientes soluciones no son rápidas y requieren preparación. Pero las puede considerar para evitar el problema a largo plazo.

SOLUCIÓN 1: si es posible, actualice su aplicación para reutilizar las conexiones creadas. Por ejemplo, si esas conexiones son debidas a conexiones internas a la base de datos, en lugar de crear, consultar y cerrar, intente reutilizar la conexión todo lo posible. Esto reducirá enormemente el número de conexiones en estado TIME_WAIT en la mayoría de los casos.

SOLUCIÓN 2: Otra posible solución es usar varias IPs para el mismo servicio y balancearlas a través de DNS (por ejemplo). De esta manera expandirá las posibles combinaciones de localizaciones para TCP que están disponibles, y así, expandirá el número de puertos efímeros que están disponibles. Cada IP disponible y sirviendo el servicio duplicará su rango.

En cualquier caso, la SOLUCIÓN 1 es con mucho mejor que la SOLUCIÓN 2. Es mejor tener un servicio consumiendo menos recursos.

Posted in: KB, Linux Networking

Leave a Comment (0) →