LINUX.ORG.RU
ФорумAdmin

Ограничение на количество TCP соединений в Debian

 , ,


1

5

Существует ли сабж?

Програмка нормально работает, пока не набирается соединений под 10К. А потом к ней получается подключится с 50%-5% вероятностью.

t# telnet 127.0.0.1 5697 Trying 127.0.0.1... telnet: Unable to connect to remote host: Connection timed out

Написал в /etc/sysctl.conf:

net.core.somaxconn=131072

net.ipv4.tcp_keepalive_time = 180

net.ipv4.tcp_keepalive_probes = 5

net.ipv4.tcp_keepalive_intvl = 30

net.ipv4.netfilter.ip_conntrack_max = 262144

net.netfilter.nf_conntrack_tcp_timeout_established = 28800

net.core.rmem_default = 262144

net.core.wmem_default = 262144

net.core.rmem_max = 8388608

net.core.wmem_max = 8388608

net.ipv4.netfilter.ip_conntrack_count больше чем до 30К не доходит.

Думал возможно не хватает ресурсов, LA ~0.5 - 1. Но ядра загружаются только до 30%. Стоит рискнуть абгрейдить железо? Что еще можно в настройках подёргать ..?


Думал возможно не хватает ресурсов, LA ~0.5 - 1. Но ядра загружаются только до 30%.

А на свич / маршрутизатор смотрел? Может он загибается

anonymous ()
Ответ на: комментарий от anonymous

Ээ, ты совсем другой анонимус. ТС, за него мне стыдно

anonymous ()
Ответ на: комментарий от renny

Дык при коннекте с локалхоста на локалхост число открытых сокетов же удваивается. Вот и получается что ты с 30k сессий подходишь к ~60k сокетов, ну плюс минус погрешность, а предел ЕМНИП 65535.

anonymous ()
Ответ на: комментарий от no-dashi

Как перестанет пускать — зайди на этот порт с другой машины.

Не получается.

Какой-нибудь ulimit на количество открытых файлов/дескрипторов?[.quote]

ulimit -n 1048576 пришлось подымать до максимума еще по достижению 1К соединений. По умолчанию система предполагает 1024 open files / sockets чего явно было недостаточно.

Я вот думаю.. Эта программа помимо приема входящих соединений также паралельно устанавлиет соответствующее кол-во исходящих соединений с другим демоном через TCP/IP на этом же хосте. Может ли быть такое, что заюзываются все TCP порты (0-65535) ? //Но если заканчиваются, как я могу делать исходящие соединения в других направлениях.?

И как это можно проверить? Листинг netstat'a слишком длинный.. Очередь SYN пакетов также пробовал расширять net.ipv4.tcp_max_syn_backlog= 262144 не помогает..

renny ()
Ответ на: комментарий от frob

В этом, в этом.

Как перестанет пускать — зайди на этот порт с другой машины.

В самом худшем случае соединение устанавливается с одним из 50 желающих. Как я понимаю, по факту закрытия существующего соединения, освобождается одно. Но не факт..

renny ()
Ответ на: комментарий от renny

Может ли быть такое, что заюзываются все TCP порты (0-65535) ?

Заканчиваются не порты как таковые, а порты в данной связке. Если программа с адреса 127.0.0.1 устанавливает соединение на адрес 127.0.0.1:100 (или любой другой фиксированный порт), то будет всего 65к соединений, так как у соединей различается только один параметр — порт, с которого программа устанавливает соединение.

Листинг netstat'a слишком длинный..

Записать его в файл и парсить скриптом.

mky ★★★★★ ()
Ответ на: комментарий от mky

Тобишь приложение назовем его A, слушающее порт в мир(принимает входящие на родном айпи) и открывающее исходящие соединения к программе Б на локалхосте, может перестать принимать входящие соединения из мира из-за связки A>Б в 65к соединений?

Я как бы не то что не исключаю, но и более чем уверен что связка A>B перегружена, но разве это должно как то устанавливать ограничение на входящие соединения для A?

renny ()
Ответ на: комментарий от renny

Я совершенно не предствляю, что у вас делает приложение А и как оно устроенно внутри.

Но, в принципе, такое поведение пишется даром. Я допускаю, что приложение А написано настолько криво, что приняв соединение от внешнего мира, оно пересаёт принимать новые соединения, пока не установит для свежепринятого соединенния из внешнего мира соответствующее соединение с Б.

Вижу три варианта проверки этой гипотезы. Чтение исходного кода, трассировка, эксперимент. Если исходники А доступны, то можно их поизучать.

Если исходников нет, можно попробовать сделать трассировку А, системные вызовы, связанные с сетевой активностью, записывать в файл и потом долго его анализировать (man strace).

Или, можно посмотреть поведение А на малом числе соединений (когда всё должно хорошо работать), но при условии DROP части пакетов между А и Б (iptables -m statistic nth --tcp-flags SYN).

mky ★★★★★ ()

net.ipv4.netfilter.ip_conntrack_count больше чем до 30К не доходит.

Видимо, потому что у вас «net.ipv4.ip_local_port_range» дефолтный ( 32768 61000), то есть, ваше приложение А может установить всего 28232 коннектов к приложению Б.

mky ★★★★★ ()
Ответ на: комментарий от mky

Блин, я так надеялся что трабл действительно в «net.ipv4.ip_local_port_range».. Как бы все логично, но расширить до «16384 61000» не помогло совсем. Дошло до ~33К и снова та же история.

исходы есть, это pushpoold jgarzik'a. Пока разбросаю нагрузку на разные сервера, как освободятся руки буду ковыряться в кишках. Отпишу если что получиться.. Спасибо за дельные советы.

renny ()
7 марта 2013 г.
Ответ на: комментарий от renny

Проблема решилась обновлением bitcoind до последней версии 0.8.0.

Известно, pushpoold работает как прокси между клиентами и bitcoind. А поскольку у старой версии не была реализована многопоточность, вероятно он не справлялся с запросами пушпула и последний тоже застрявал.

renny ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.