tcp_tw_recycle

15 февраля 2019

  • В ядре Линукса существуют такие параметры, включение которых чревато возникновением трудно диагностируемых ошибок.
  • Одним из них безусловно является net.ipv4.tcp_tw_recycle
  • По умолчанию он равен нулю, и некоторые интернет-ресурсы, посвящённые сетевой оптимизации Линукса, рекомендуют установить его в «1».
  • Мы настоятельно рекомендуем везде и всегда оставлять его равным нулю.
  • Главная неприятность его включения состоит в том, что проблема проявляет себя не на сервере, на котором он включен, а у клиентов этого сервера.
  • Вторая неприятность заключается в том, что проблема не возникает при одиночных соединениях, поэтому труднее воспроизводится.

Проблемы у наших клиентов:

  • Когда мы включили tcp_tw_recycle у себя, у клиентов стали подвисать все одновременные подключения к нашему серверу, кроме первого.

Проблемы у нас:

  • Когда один из наших веб-апстримов включил tcp_tw_recycle, наш Nginx стал регулярно выдавать “110 upstream timed out while connecting”.
  • Вероятность ошибки зависела от количества одновременных запросов.
  • Одиночные запросы всегда проходили нормально, что сильно сбивало нас с толку.
  • Сниффер показывал, что при включённом tcp_tw_recycle SYN-запрос нового соединения уходит upstream'у раньше, чем FIN+ACK-ответ для старого, хотя ab сначала отправляет FIN+ACK-ответ, затем SYN-запрос, но такая оптимизация не выглядит предосудительной.
  • Кроме установки tcp_tw_recycle=0, на стороне клиента (т.е. в данном случае на нашей стороне) помогал откат версии ядра с kernel-ml 4.10+ на kernel-lt 4.4, который по ряду причин для нас неприемлем.

Что ещё мы проверяли:

  • В обоих случаях мы пробовали также менять tcp_congestion — не помогло, и отключать NIC offloadings — тоже не помогло.


← Назад в Блог