Назад | Перейти на главную страницу

Достижение максимального количества сокетов TIME_WAIT (пробовал tcp_fin_timeout)

tl; dr: Как заставить ядро ​​сбросить TIME_WAIT/ закрытие розеток как можно сильнее и быстрее? Меня не волнует потеря данных, поскольку я их не отправляю.


В настоящее время я запускаю небольшой тестовый сценарий на очень изолированной машине.
Я запускаю две простые программы C друг против друга на одном хосте, где цель приложения - подключить клиентский сокет к серверному сокету и сбросить его как можно быстрее.

Приложение работает достаточно быстро, чтобы заблокировать пул сокетов (или, скорее, fd), вызывая "Can't bind to address" на стороне клиента, и причина этого, по-видимому, в TIME_WAIT на каждом доступном слоте сокета. Я проверил это с ss -s.

Чтобы решить эту проблему, я помню, как установил три значения в sysctl. И этого раньше было достаточно для решения проблемы, но почему-то выставили следующее:

net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 1

Больше не работает. Это просто снижает количество подключений в секунду с 20k + до примерно 4 в минуту.

Я мог вспомнить неправильные настройки в sysctl net конфигурации выше, но я имел обыкновение получать с этой машины примерно 20k + соединений в секунду.
Так почему же это внезапно привело меня в тупик до 4 / сек?

Та же машина, i7 работает против 127.0.0.1 с минимальной настройкой Arch Linux.
Моим основным источником информации для попытки настройки были: Как уменьшить количество сокетов за TIME_WAIT?

Редактировать:

Похоже, что tcp_fin_timeout не влияет на систему.

Судя по этой картинке, еще пара тысяч подключений timewait даже если сервер (вверху слева) и клиент (вверху справа) больше не выполняет никаких подключений.

В конце 10-секундного запуска мне удалось установить 18 805 подключений, что не является большой дырой для этой машины (~ 36 тыс. Сокетов TIME_WAIT, потому что сервер и клиент находятся на одной машине).

Почему нет tcp_fin_timeout разрыв соединения через секунду? Это определенно ОС не соблюдает мой пользовательский tcp_fin_timeout.