Привет, есть идеи во что может упираться, что за магическая

цифра такая в 400 K?

400к time_wait сокетов ?

я бы скорее думал почему их так много. Пробовали net.ipv4.tcp_tw_recycle=1?

99% что это http1 (.1) без keep alive - самое частое

Да, вот в рамках диагностики пытаюсь разобраться 🙂

Ну если вам реюз не нужен то можно крутануть tcp_fin_timeout Но лучше, конечно, понять и исправить причину

у меня такого параметра нет

freebsd?

бубунта 5.13.0-27-generic

значит не там смотрите Это от sysctl

вы бы написали что это. я ставлю на ограничение в которое уперся сервак, но какое оно зависит от того, что за сервер. 1) оно может у него как в конфиге быть прописано, 2) или выражаться в лимите на число открытых файловых дескрипторов, тут наврядли т.к. в time wait вроде он уже не занят 3) или лимите на число окрытых портов если все соединения с малого числа точек. Например у вас 8 серверов у которых ip_local_port_range поставлен так что сокетов 50 тыс, их 8 и они долбятся в один сервак. Вам было бы если честно полезней вывести ошибки на создании сокета, если их нет то time wait фигня.

В ещё можно осторожно tcp_tw_reuse...

А dmesg не смотрели?

Сокеты они там в бакетах и количество бакетов задаётся как и их размер - так что 400к это вероятно от этих настроек лимит

# sysctl net.ipv4.tcp_tw_recycle sysctl: cannot stat /proc/sys/net/ipv4/tcp_tw_recycle: No such file or directory # sysctl -a | grep recycle <пусто>

1. Включив tcp_tw_recycle, вы говорите ядру Linux, чтобы оно использовало в качестве MSL не константу, а рассчитало его на основе особенностей именно вашей сети. Как правило (если у вас не dial-up), включение tcp_tw_recycle значительно сокращает время нахождения соединения в состоянии TIME_WAIT. Но здесь есть подводный камень: перейдя в состояние TIME_WAIT, ваш сетевой стек при включенном tcp_tw_recycle будет отвергать все пакеты с IP второй стороны, участвовавшей в соединении. Это может вызывать ряд проблем с доступностью при работе из-за NAT, с чем мы и столкнулись в приведенном выше кейсе. Проблема крайне сложно диагностируется и не имеет простой процедуры воспроизведения/повторяемости, поэтому мы рекомендуем проявлять крайнюю осторожность при использовании tcp_tw_recycle 2. в тырнетах рекомендовалось добавить в ядро параметр для ускоренного освобождения сокета net.ipv4.tcp_tw_recycle = 0 но при перезапуске конфига влезала ошибка # sysctl -p /etc/sysctl.conf sysctl: cannot stat /proc/sys/net/ipv4/tcp_tw_recycle: No such file or directory Небольшой гуглеж дает ответ, что параметр net.ipv4.tcp_tw_recycle был выпилен из ядра на версии 4.12, ввиду того, что имелись проблемы с работой из-за NAT. Чекаем версию ядра # uname -a Linux mail.xxxx 5.18.4-1.el8.elrepo.x86_64 и понимаем что это как раз про нас. Вместо него рекомендуется устанавливать параметр net.ipv4.tcp_tw_reuse = 1 который позволяет использовать TIME-WAIT сокет повторно. по умолчанию в системе взведено значение 2, которое позволяет этот функционал только для loopbac

Мы один раз ловили очень неприятный факап. У нас было 3 балансера внутренних для grpc, и в какой-то момент чуваки задеплоили web чат который сделал 10М живых сокетов (открывал постоянно, а не когда чат начался), и у серваков просто не хватило пар srcip-srcport-dstip-dstport, для внутренних IP/портов (для внешних как раз не проблема т.к. там один пользователь один ip). Это я к тому что даже если там нет ограничения в 400К его легко можно достичь конфигурацией нескольких серверов вокруг

Как сделать серверу плохо я и так знаю, лучше расскажи как сделать хорошо )))

так вы расскажите, что за сервер, что за соединения. Я думаю у вас на сервер наведена ужасная порча, ее очень сложно снять просто так, нужна либо фотография сервера либо описание, что он делает 🙂

Не, эт юмор. Вопрос начальный не мой .

небольшая вводная: Есть кластер с постоянной нагрузкой гдето 50000rps. Периодически в часы пик всё начинает резко тупить, но при этом на графиках по ресурсам особых аномалий нет. Но при этом соединение между сервисами начинает устанавливаться куда медленнее чем обычно. Внимание привлёк этот график, т.к. есть подозрение что упираемся в какой-то лимит по числу открытых сокетов.

tw если мы этот график читаем верно это не открытые, а почти закрытые

общее число сокетов 🙂

Сервер общается с малым количеством внутренних серверов, т.е. это бекенд и общается с фронтом. Или сервер сам фронт и отвечает разным пользователям? смотрите можно подтвердить, что соединение не устанавливается с помощью tcpdump с этого сервера. Дальше если соединение пришло, но не установилось вы смотрите код ошибки на сервере, а если никто даже не пытался установить, то смотрите смотрите код ошибки на клиенте.

Проблема была в количестве устанавливаемых соединений nginx-ingress-контроллера ко внутренним подам. Сам nginx-ingress-controller работал в host network. И при каждом обращении к подам занимал порт на адресе ноды, таких подключений было очень много, именно из-за них заканчивались свободные порты и не могли установиться новые подключения. Решение: Передеплоить nginx-ingress в: - Deployment вместо Daemonset - Количество реплик x3 от общего числа нод - переключить externalTraficPolicy из Cluster в Local (в этом случае для входящих подключений используется DstNAT вместо SourceNAT, который не занимает портов на ноде)

А у тебя автоскейлинг нод есть? Если да, не боишься такого https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-41/Layer-3/Equal-Cost-Multipath-Load-Sharing-Hardware-ECMP/#resilient-hash-buckets ?

Неа. У меня железки. Но спасибо за предостережение