Apakah berbahaya untuk mengubah nilai / proc / sys / net / ipv4 / tcp_tw_reuse?

Kami memiliki beberapa sistem produksi yang baru-baru ini dikonversi menjadi mesin virtual. Ada aplikasi kami yang sering mengakses database MySQL, dan untuk setiap permintaan itu membuat koneksi, permintaan, dan memutus koneksi itu.

Itu bukan cara yang tepat untuk query (saya tahu), tetapi kami memiliki kendala yang sepertinya tidak bisa kami selesaikan. Bagaimanapun, masalahnya adalah ini: sementara mesin itu adalah host fisik, program berjalan dengan baik. Setelah dikonversi ke mesin virtual, kami melihat masalah koneksi yang terputus-putus ke database. Ada, pada satu titik, 24.000+ koneksi soket di TIME_WAIT (pada host fisik, yang paling saya lihat adalah 17000 - tidak baik, tetapi tidak menyebabkan masalah).

Saya ingin koneksi ini digunakan kembali, sehingga kita tidak melihat masalah koneksi, dan karenanya:

Pertanyaan:

Apakah boleh untuk menetapkan nilai tcp_tw_reuse ke 1? Apa bahaya yang jelas? Apakah ada alasan saya tidak boleh melakukannya?

Juga, apakah ada cara lain untuk mendapatkan sistem (RHEL / CentOS) untuk mencegah begitu banyak koneksi masuk ke TIME_WAIT, atau membuatnya digunakan kembali?

Terakhir, apa yang akan dilakukan dengan mengubah tcp_tw_recycle, dan apakah itu akan membantu saya?

Di muka, terima kasih!

Anda dapat dengan aman mengurangi waktu henti, tetapi Anda mungkin mengalami masalah dengan koneksi yang tidak benar tertutup pada jaringan dengan kehilangan paket atau jitter. Saya tidak akan mulai menyetel pada 1 detik, mulai pada 15-30 dan mulai bekerja.

Juga, Anda benar-benar perlu memperbaiki aplikasi Anda.

RFC 1185 memiliki penjelasan yang baik di bagian 3.2:

Ketika koneksi TCP ditutup, penundaan 2 * MSL dalam status TIME-WAIT mengikat pasangan soket selama 4 menit (lihat Bagian 3.5 dari [Postel81]. Aplikasi yang dibangun di atas TCP yang menutup satu koneksi dan membuka yang baru (mis. , koneksi transfer data FTP menggunakan mode Stream) harus memilih pasangan soket baru setiap kali.Tunda ini memiliki dua tujuan yang berbeda:

 (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 

---

* Catatan: Dapat diperdebatkan bahwa pihak yang mengirimkan FIN mengetahui tingkat keandalan yang dibutuhkannya, dan oleh karena itu pihaknya harus dapat menentukan lamanya keterlambatan WAKTU-TUNGGU bagi penerima FIN. Ini dapat dilakukan dengan opsi TCP yang sesuai di segmen 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.

Ini tidak menjawab pertanyaan Anda (dan terlambat 18 bulan), tetapi menyarankan cara lain untuk membuat porta aplikasi lama Anda menggunakan kembali port:

Alternatif yang berguna untuk pengaturan tcp_tw_reuse(atau tcp_tw_recycle) pada sistem adalah dengan memasukkan perpustakaan bersama (menggunakan LD_PRELOAD) ke aplikasi Anda; perpustakaan itu kemudian dapat mengizinkan penggunaan kembali port. Ini membuat aplikasi lawas Anda memungkinkan penggunaan kembali port tanpa memaksakan ini pada semua aplikasi di sistem Anda (tidak perlu modifikasi aplikasi), sehingga membatasi dampak tweak Anda. Sebagai contoh,

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

Pustaka bersama ini harus mencegat socket()panggilan, memanggil soket asli (), dan mengatur SO_REUSEADDR dan / atau SO_REUSEPORT pada soket yang dikembalikan. Lihatlah http://libkeepalive.sourceforge.net untuk contoh bagaimana melakukan ini (ini menghidupkan keepalives, tetapi menyalakan SO_REUSEPORT sangat mirip). Jika aplikasi lawas Anda yang berperilaku buruk menggunakan IPv6, ingatlah untuk mengubah jalur 55 libkeepalive.cdari

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

untuk

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

Jika Anda buntu, kirim saya email dan saya akan menulis kode dan mengirimkannya kepada Anda.

Saya pikir tidak apa-apa untuk mengubah nilai ini menjadi 1. Cara yang lebih tepat adalah dengan menggunakan perintah:

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

Tidak ada bahaya nyata yang saya ketahui, tetapi pencarian Google cepat menghasilkan tautan ini yang menegaskan bahwa itu tcp_tw_reuseadalah alternatif yang lebih baik daripada tcp_tw_recycle, tetapi harus digunakan dengan hati-hati.

Koneksi tidak dapat digunakan kembali jika mereka dalam TIME WAIT. Jika Anda tidak memiliki packet loss pada jaringan antara aplikasi dan MySQL, Anda dapat menurunkan batas waktu.

Namun solusi terbaik adalah menggunakan koneksi persisten ke database dan kumpulan koneksi.