Pregunta ¿Es peligroso cambiar el valor de / proc / sys / net / ipv4 / tcp_tw_reuse?


Tenemos un par de sistemas de producción que recientemente se convirtieron en máquinas virtuales. Existe una aplicación nuestra que accede con frecuencia a una base de datos MySQL, y para cada consulta crea una conexión, consulta y desconecta esa conexión.

No es la forma adecuada de realizar una consulta (lo sé), pero tenemos limitaciones que parece que no podemos resolver. De todos modos, el problema es el siguiente: mientras la máquina era un host físico, el programa funcionó bien. Una vez convertido a una máquina virtual, notamos problemas de conexión intermitentes a la base de datos. Hubo, en un momento dado, más de 24000 conexiones de socket en TIME_WAIT (en el host físico, lo más que vi fue 17000, no es bueno, pero no causa problemas).

Me gustaría que estas conexiones se reutilizaran, para que no veamos ese problema de conexión, y así:

Preguntas:

¿Está bien establecer el valor de tcp_tw_reuse en 1? ¿Cuáles son los peligros obvios? ¿Hay alguna razón por la que deba Nunca ¿hazlo?

Además, ¿hay alguna otra forma de que el sistema (RHEL / CentOS) evite que tantas conexiones entren en TIME_WAIT o se reutilicen?

Por último, ¿qué haría cambiar tcp_tw_recycle, y eso me ayudaría?

De antemano, gracias!


9
2018-02-11 20:06


origen


Esta enlazar explica bien el peligro de tcp_tw_recycle y tcp_tw_reuse. No uses eso.


Respuestas:


Puede reducir de forma segura el tiempo de inactividad, pero puede tener problemas con las conexiones cerradas incorrectamente en redes con pérdida de paquetes o fluctuación de fase. No empezaría a sintonizar en 1 segundo, comenzaría en 15-30 y seguiría hacia abajo.

Además, realmente necesitas arreglar tu aplicación.

RFC 1185 Tiene una buena explicación en la sección 3.2:

Cuando se cierra una conexión TCP, un   retraso de 2 * MSL en TIME-WAIT        el estado conecta el par de enchufes durante 4 minutos (consulte la Sección 3.5 de        [Postel81]. Aplicaciones construidas sobre TCP que cierran una conexión        y abra una nueva (por ejemplo, una conexión de transferencia de datos FTP usando        Modo de transmisión) debe elegir un nuevo par de sockets cada vez. Este retraso        Sirve dos propósitos diferentes:

 (a)  Implement the full-duplex reliable close handshake of TCP. 

      The proper time to delay the final close step is not really 
      related to the MSL; it depends instead upon the RTO for the 
      FIN segments and therefore upon the RTT of the path.* 
      Although there is no formal upper-bound on RTT, common 
      network engineering practice makes an RTT greater than 1 
      minute very unlikely.  Thus, the 4 minute delay in TIME-WAIT 
      state works satisfactorily to provide a reliable full-duplex 
      TCP close.  Note again that this is independent of MSL 
      enforcement and network speed. 

      The TIME-WAIT state could cause an indirect performance 
      problem if an application needed to repeatedly close one 
      connection and open another at a very high frequency, since 
      the number of available TCP ports on a host is less than 
      2**16.  However, high network speeds are not the major 
      contributor to this problem; the RTT is the limiting factor 
      in how quickly connections can be opened and closed. 
      Therefore, this problem will no worse at high transfer 
      speeds. 

 (b)  Allow old duplicate segements to expire. 

      Suppose that a host keeps a cache of the last timestamp 
      received from each remote host.  This can be used to reject 
      old duplicate segments from earlier incarnations of the 

* Nota: se podría argumentar que el lado que envía un FIN sabe   qué grado de fiabilidad necesita,   y por lo tanto debería ser capaz de   determinar la longitud de la   TIME-WAIT delay para las FIN's   recipiente. Esto podría ser   logrado con un TCP apropiado   Opción en segmentos FIN.

      connection, if the timestamp clock can be guaranteed to have 
      ticked at least once since the old conennection was open. 
      This requires that the TIME-WAIT delay plus the RTT together 
      must be at least one tick of the sender's timestamp clock. 

      Note that this is a variant on the mechanism proposed by 
      Garlick, Rom, and Postel (see the appendix), which required 
      each host to maintain connection records containing the 
      highest sequence numbers on every connection.  Using 
      timestamps instead, it is only necessary to keep one quantity 
      per remote host, regardless of the number of simultaneous 
      connections to that host.

8
2018-02-17 02:43



Gracias por la explicación. El problema está en la biblioteca, sobre la que no tengo control. - Sagar


Esto no responde a su pregunta (y llega con 18 meses de retraso), pero sugiere otra forma de hacer que los puertos de reutilización de su aplicación heredada:

Una alternativa útil a la configuración tcp_tw_reuse (o tcp_tw_recycle) en el sistema es insertar una biblioteca compartida (usando LD_PRELOAD) en su aplicación; esa biblioteca puede entonces permitir la reutilización del puerto. Esto hace que su aplicación heredada permita la reutilización de puertos sin forzar esto en todas las aplicaciones en su sistema (no se requiere ninguna modificación de su aplicación), lo que limita el impacto de su ajuste. Por ejemplo,

    LD_PRELOAD=/opt/local/lib/libreuse.so ./legacy_app

Esta biblioteca compartida debe interceptar el socket() llame, llame al socket real () y establezca SO_REUSEADDR y / o SO_REUSEPORT en el socket devuelto. Mirar http://libkeepalive.sourceforge.net para ver un ejemplo de cómo hacerlo (esto activa los keepalives, pero activar SO_REUSEPORT es muy similar). Si su aplicación heredada de mala conducta utiliza IPv6, recuerde cambiar la línea 55 de libkeepalive.c desde

    if((domain == PF_INET) && (type == SOCK_STREAM)) {

a

    if(((domain == PF_INET) || (domain == PF_INET6)) && (type == SOCK_STREAM)) {

Si estás atascado, envíame un correo electrónico y te escribiré el código y te lo enviaré.


6
2017-11-15 23:51





Creo que está bien cambiar este valor a 1. Una forma más apropiada podría ser usar el comando:

[root@server]# sysctl -w net.ipv4.tcp_tw_reuse=1

No hay peligros obvios que conozca, pero una rápida búsqueda en Google produce esto enlazar lo que afirma que tcp_tw_reuse es la mejor alternativa que tcp_tw_recycle, pero se debe utilizar con precaución independientemente.


5
2018-02-17 02:05



No, eso no es lo que dice. Dice (hablando de tcp_tw_reuse), "Generalmente es una alternativa más segura a tcp_tw_recycle". - Fantius


La conexión no se puede reutilizar si están en TIEMPO DE ESPERA. Si no tiene pérdida de paquetes en la red entre la aplicación y MySQL, puede reducir el tiempo de espera.

Sin embargo, la mejor solución es utilizar conexiones persistentes hacia la base de datos y un grupo de conexiones.


0
2018-02-14 19:22



En realidad, eso no es necesariamente cierto. Algunos sistemas permitirán el uso de sockets en TIME_WAIT, que es de lo que se trata mi pregunta. No si es posible, sino cuáles son los peligros obvios y no tan obvios. ¡Gracias! - Sagar