È pericoloso cambiare il valore di / proc / sys / net / ipv4 / tcp_tw_reuse?

Abbiamo un paio di sistemi di produzione che sono stati recentemente convertiti in macchine virtuali. Esiste una nostra applicazione che accede frequentemente a un database MySQL e per ogni query crea una connessione, interroga e disconnette tale connessione.

Non è il modo appropriato di interrogare (lo so), ma abbiamo dei vincoli che non possiamo sembrare aggirare. Comunque, il problema è questo: mentre la macchina era un host fisico, il programma funzionava bene. Una volta convertito in una macchina virtuale, abbiamo notato problemi di connessione intermittente al database. C'erano, a un certo punto, oltre 24000 connessioni socket in TIME_WAIT (sull'host fisico, il massimo che ho visto era 17000 - non buono, ma non causa problemi).

Vorrei che queste connessioni venissero riutilizzate, in modo da non vedere quel problema di connessione, e quindi:

Domande:

Va bene impostare il valore di tcp_tw_reuse su 1? Quali sono gli evidenti pericoli? C'è qualche motivo per cui non dovrei mai farlo?

Inoltre, c'è un altro modo per ottenere il sistema (RHEL / CentOS) per impedire a tante connessioni di entrare in TIME_WAIT o farle riutilizzare?

Infine, cosa farebbe cambiando tcp_tw_recycle e mi aiuterebbe?

In anticipo, grazie!

È possibile ridurre in modo sicuro i tempi di inattività, ma si possono verificare problemi con connessioni non adeguatamente chiuse su reti con perdita di pacchetti o jitter. Non vorrei iniziare la sintonizzazione a 1 secondo, iniziare alle 15-30 e scendere fino in fondo.

Inoltre, devi davvero riparare la tua applicazione.

RFC 1185 ha una buona spiegazione nella sezione 3.2:

Quando una connessione TCP viene chiusa, un ritardo di 2 * MSL nello stato TIME-WAIT lega la coppia di socket per 4 minuti (vedere la Sezione 3.5 di [Postel81]. Applicazioni costruite su TCP che chiudono una connessione e ne aprono una nuova (ad es. , una connessione di trasferimento dati FTP che utilizza la modalità Stream) deve scegliere una nuova coppia di socket ogni volta. Questo ritardo ha due scopi diversi:

 (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: si potrebbe affermare che la parte che sta inviando un FIN conosce il grado di affidabilità di cui ha bisogno, e quindi dovrebbe essere in grado di determinare la durata del ritardo TIME-WAIT per il destinatario del FIN. Ciò potrebbe essere realizzato con un'opzione TCP appropriata nei segmenti 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.

Questo non risponde alla tua domanda (ed è in ritardo di 18 mesi), ma suggerisce un altro modo per rendere le tue app legacy riutilizzare le porte:

Un'utile alternativa all'impostazione tcp_tw_reuse(o tcp_tw_recycle) sul sistema è quella di inserire una libreria condivisa (usando LD_PRELOAD) nella tua app; tale libreria può quindi consentire il riutilizzo della porta. Questo rende la tua app legacy consentire il riutilizzo delle porte senza forzarlo su tutte le app sul tuo sistema (non è necessaria alcuna modifica dell'app), limitando così l'impatto del tuo tweak. Per esempio,

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

Questa libreria condivisa deve intercettare la socket()chiamata, chiamare il socket reale () e impostare SO_REUSEADDR e / o SO_REUSEPORT sul socket restituito. Guarda http://libkeepalive.sourceforge.net per un esempio di come farlo (questo attiva keepalives, ma l'attivazione di SO_REUSEPORT è molto simile). Se l'app legacy mal funzionante utilizza IPv6, ricordati di cambiare la riga 55 di libkeepalive.cda

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

per

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

Se sei bloccato, inviami un'e-mail e scriverò il codice e te lo invierò.

Penso che vada bene cambiare questo valore in 1. Un modo più appropriato potrebbe essere quello di usare il comando:

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

Non ci sono pericoli evidenti che io conosca, ma una rapida ricerca su Google produce questo link che afferma che tcp_tw_reuseè l'alternativa migliore di tcp_tw_recycle, ma dovrebbe essere usata con cautela a prescindere.

La connessione non può essere riutilizzata se sono in ATTESA TEMPO. Se non si riscontra una perdita di pacchetti sulla rete tra l'applicazione e MySQL, è possibile ridurre il timeout.

Tuttavia, la soluzione migliore è utilizzare connessioni persistenti verso il database e un pool di connessioni.