Чи небезпечно змінювати значення / proc / sys / net / ipv4 / tcp_tw_reuse?

У нас є кілька виробничих систем, які нещодавно були перетворені на віртуальні машини. Існує наша програма, яка часто звертається до бази даних MySQL, і для кожного запиту вона створює з'єднання, запитує та відключає це з'єднання.

Це не відповідний спосіб запиту (я знаю), але у нас є обмеження, які ми, здається, не можемо обійти. У всякому разі, проблема в цьому: поки машина була фізичним вузлом, програма працювала чудово. Перетворившись у віртуальну машину, ми помітили періодичні проблеми з підключенням до бази даних. Одного разу в TIME_WAIT було підключено 24000+ сокетів (на фізичному хості найбільше я бачив - 17000 - це не добре, але не створювало проблем).

Я хотів би, щоб ці з'єднання були використані повторно, щоб ми не бачили проблеми з підключенням, і так:

Запитання:

Чи нормально встановити значення tcp_tw_reuse в 1? Які очевидні небезпеки? Чи є якась причина, щоб я ніколи цього не робив?

Крім того, чи є інший спосіб отримати систему (RHEL / CentOS), щоб запобігти переходу стільки з’єднань у TIME_WAIT або змусити їх повторно використовувати?

Нарешті, що може змінити tcp_tw_recycle, і чи допоможе це мені?

Заздалегідь дякую!

Ви можете безпечно скоротити час вниз, але у вас можуть виникнути проблеми із неправильно закритими з'єднаннями в мережах з втратою пакету або тремтінням. Я б не почав налаштовуватись за 1 секунду, почніть з 15-30 і працюйте вниз.

Також вам дійсно потрібно виправити свою заявку.

У розділі 3.2 RFC 1185 є чітке пояснення:

Коли TCP-з'єднання закрито, затримка 2 * MSL у стані TIME-WAIT зв’язує пару розеток на 4 хвилини (див. Розділ 3.5 [Postel81]. Програми, побудовані на TCP, що закривають одне з'єднання та відкривають нове (наприклад, , з'єднання для передачі даних FTP в режимі Stream) повинен кожен раз вибирати нову пару розеток. Ця затримка служить двом різним цілям:

 (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 

---

* Примітка. Можна стверджувати, що сторона, що надсилає FIN, знає, який ступінь надійності їй потрібен, і тому він повинен мати можливість визначати тривалість затримки TIME-WAIT для одержувача FIN. Це може бути досягнуто за допомогою відповідної опції TCP у сегментах 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.

Це не відповідає на ваше запитання (а це пізніше на 18 місяців), але пропонує інший спосіб зробити застаріле додаток для повторного використання портів:

Корисна альтернатива налаштуванню tcp_tw_reuse(або tcp_tw_recycle) в системі - вставити спільну бібліотеку (за допомогою LD_PRELOAD) у ваш додаток; потім бібліотека може дозволити повторне використання порту. Це робить ваш застарілий додаток дозволити повторне використання портів, не примушуючи це застосовуватись до всіх додатків у вашій системі (не потрібно змінювати додаток), тим самим обмежуючи вплив налаштування. Наприклад,

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

Ця спільна бібліотека повинна перехоплювати socket()виклик, викликати справжній сокет () та встановлювати SO_REUSEADDR та / або SO_REUSEPORT на поверненому сокеті. Подивіться на http://libkeepalive.sourceforge.net для прикладу того, як це зробити (це вмикається у ключів, але увімкнення SO_REUSEPORT дуже схоже). Якщо ваш застарілий додаток використовує IPv6, не забудьте змінити рядок 55 libkeepalive.cз

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

до

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

Якщо ви застрягли, надішліть мені електронний лист, і я напишу код і надішлю його вам.

Я думаю, що цілком нормально змінити це значення на 1. Більш правильним способом може бути використання команди:

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

Яких явних небезпек я не знаю, але швидкий пошук в Google створює це посилання, яке підтверджує, що tcp_tw_reuseє кращою альтернативою, ніж tcp_tw_recycle, але його слід застосовувати з обережністю незалежно.

З'єднання не можна повторно використовувати, якщо вони перебувають у ЧАСІ ЗАЧЕКАЙТЕ. Якщо у вас немає втрати пакетів у мережі між додатком та MySQL, ви можете зменшити час очікування.

Однак найкращим рішенням є використання стійких підключень до бази даних та пулу з'єднань.