LINUX.ORG.RU
решено Форум — Development  

Проблема с лишними соединениями

 ,


0

1

Я разработчик одного веб приложения на питоне. Оно создает множество соединений к другим ресурсам в интернете. Есть проблема. У меня есть подозрение, что часть соединений не закрывается либо их слишком много создается и они очень подозрительно выгледят. Я выполняю комманду sudo lsof -p 24942 (24942 - это айдишка процесса приложения) Часть результата выглядит примерно так: 

COMMAND   PID     USER   FD      TYPE     DEVICE SIZE/OFF       NODE NAME
python  24942 www-data  226u     IPv4 1299540398      0t0        TCP politepol.com:33258->a2-19-32-85.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
python  24942 www-data  232u     IPv4 1299639239      0t0        TCP localhost:1234->localhost:45996 (ESTABLISHED)
python  24942 www-data  239u     IPv4 1299588950      0t0        TCP politepol.com:34910->a2-19-32-85.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
python  24942 www-data  241u     IPv4 1299623513      0t0        TCP politepol.com:43044->a23-32-243-165.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
python  24942 www-data  242u     IPv4 1299524433      0t0        TCP politepol.com:52442->a2-19-32-85.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
python  24942 www-data  243u     IPv4 1299622317      0t0        TCP politepol.com:42786->a23-32-243-165.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
python  24942 www-data  247u     IPv4 1299531657      0t0        TCP politepol.com:57440->a2-19-32-85.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
python  24942 www-data  250u     IPv4 1299627881      0t0        TCP politepol.com:46228->a23-32-243-165.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
python  24942 www-data  255u     IPv4 1299637218      0t0        TCP localhost:1234->localhost:45580 (ESTABLISHED)
python  24942 www-data  263u     IPv4 1299640091      0t0        TCP localhost:1234->localhost:46498 (ESTABLISHED)
python  24942 www-data  265u     IPv4 1299544144      0t0        TCP politepol.com:34574->a2-19-32-85.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
python  24942 www-data  267u     IPv4 1299641353      0t0        TCP localhost:1234->localhost:46124 (ESTABLISHED)
python  24942 www-data  268u     IPv4 1299547756      0t0        TCP politepol.com:37850->a2-19-32-85.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
python  24942 www-data  273u     IPv4 1299640098      0t0        TCP localhost:1234->localhost:46530 (ESTABLISHED)
python  24942 www-data  281u     IPv4 1299532094      0t0        TCP politepol.com:55680->a2-19-32-85.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
python  24942 www-data  286u     IPv4 1299582554      0t0        TCP politepol.com:60040->a2-19-32-85.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
python  24942 www-data  287u     IPv4 1299591864      0t0        TCP politepol.com:36188->a2-19-32-85.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
python  24942 www-data  289u     IPv4 1299574765      0t0        TCP politepol.com:55282->a2-19-32-85.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
python  24942 www-data  291u     IPv4 1299286603      0t0        TCP politepol.com:39880->185.215.152.26:http (ESTABLISHED)
python  24942 www-data  313u     IPv4 1299533969      0t0        TCP politepol.com:56650->a2-19-32-85.deploy.static.akamaitechnologies.com:https (ESTABLISHED)

Мне не понятно что значат соединения вида localhost:1234->localhost:52048 и не ясно откуда берутся соединения с deploy.static.akamaitechnologies.com. Из приложения не видно соединений или редиректов на домен deploy.static.akamaitechnologies.com.

В чем может быть проблема? Может кто-нибудь подсказать?



Последнее исправление: taronto (всего исправлений: 1)
← Как переопределить поведение сисколов для определённого процесса?
с++, nasm, массивы и деление →

не ясно откуда берутся соединения с deploy.static.akamaitechnologies.com?

ну дэк твой парсер-генератор рссок лазиет по сайтам, ресурсы сайтов лежат на CDN, а это адрес его. чего непонятного то?

что значат соединения вида localhost:1234->localhost:52048

ну а это локальные коннекты у тебя. микросервисы какието небось нахипстерил, или к базе данных конектишся не по UDS.

genryRar ★★
()

Если не ошибаюсь localhost:1234->localhost:52048 какие-то локальные клиентские соединения.

deploy.static.akamaitechnologies.com:https - какой-то интернет кеш вроде как лет 5 назад был.

Самый главный вопрос:

У меня есть подозрение, что часть соединений не закрывается либо их слишком много создается и они очень подозрительно выгледят

На чем основано данное утверждение? Что вызывает данные подозрения?

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

ну дэк твой парсер-генератор рссок лазиет по сайтам, ресурсы сайтов лежат на CDN

Дело в том что я вижу какие запросы делает приложение и следов домена deploy.static.akamaitechnologies.com нигде нет. Если бы был запрос/редирект на ресурс, то стало бы понятно. Я уже грешу на малваре, хотя кто будет лепить малваре под мое приложение тоже не понятно

что значат соединения вида localhost:1234->localhost:52048

ну а это локальные коннекты у тебя. микросервисы какието небось нахипстерил, или к базе данных конектишся не по UDS.

У меня приложение работает в 5-10 потоков (должно в один, но это отдельная история), а соединений вида localhost:1234->localhost:52048 сильно больше десяти (на фрагменте этого не видно, но там их больше). А на поток больше 1-го соединения не сделаешь, значит эти соединения берутся еще откуда-то. Если я правильно все понимаю

taronto
() автор топика
Ответ на: комментарий от deterok

У меня есть подозрение, что часть соединений не закрывается либо их слишком много создается и они очень подозрительно выгледят

На чем основано данное утверждение? Что вызывает данные подозрения?

Где-то месяц назад появилась проблема. Раз в 4 дня стал появляться иксепшн: socket.error: [Errno 24] Too many open files или _mysql_exceptions.OperationalError: (2004, «Can't create TCP/IP socket (24)») и еще раньше была ошибка exception.IOError: [Errno 24] Too many open files

Все соединения аккуратно закрываются, если бы не закрывались то приложение прекратило бы работу гораздо раньше (число соединений исчисляется миллионами в сутки), а не через 4 дня

И я начал копать. Я думал, что проблема в том, что диск не дает закрыть файлы и убрал весь код, который открывает файлы на диске, заменил их на хранение данных в memcached. Это не принесло никаких результатов. Я подумал, что соединения не закрываются в каком-то другом месте и тут я обратился к команде lsof. И результаты этой комманды меня заинтересовали. То что соединения вида localhost:1234->localhost:52048 и deploy.static.akamaitechnologies.com могут занимать >95% соединений, а временами список состоит полностью из deploy.static.akamaitechnologies.com меня и привлекло. И вроде как соединения вида localhost:1234->localhost:52048 со временем самоликвидируются, но соединения к deploy.static.akamaitechnologies.com не склонны к уменьшению

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

А на поток больше 1-го соединения не сделаешь, значит эти соединения берутся еще откуда-то

наркоман штоль? тебебы разобраться как сокеты работают

Дело в том что я вижу какие запросы делает приложение и следов домена deploy.static.akamaitechnologies.com нигде нет. Если бы был запрос/редирект на ресурс, то стало бы понятно.

считай что это «редирект». разберись штоль что таке маршрутизация, cdnы и что вообще показывает lsof

И вроде как соединения вида localhost:1234->localhost:52048 со временем самоликвидируются, но соединения к deploy.static.akamaitechnologies.com не склонны к уменьшению

дай угадаю - парсишь то с одного адреса? ну дык кажись это такой способ борьбы с хитрожопыми - вместо того чтоб плевать в тебя 401 ошибку, тебе включают slow-headers подобную штуку и твой говнокод висит и ждет данных, которых ему никто не собирается отправлять. хотя заголовки скарее всего идут, шоб ты по таймауту не рвал. или у тебя вообще таймаут только на коннект стоит.

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

genryRar ★★
()
Последнее исправление: genryRar (всего исправлений: 1)
Ответ на: комментарий от genryRar

А на поток больше 1-го соединения не сделаешь, значит эти соединения берутся еще откуда-то

наркоман штоль? тебебы разобраться как сокеты работают

Я имел ввиду, что все соединения я закрываю и паралельно несколько открытых соединений не держу

считай что это «редирект». разберись штоль что таке маршрутизация, cdnы и что вообще показывает lsof

Я знаю, что такое маршрутизация и cdn. Но мое приложение не обращается на deploy.static.akamaitechnologies.com:https и никаких редиректов на такие страницы приложение не регистрирует. А может мой хостинг провайдер кешировать страницы на cdn и перенаправлять мои запросы? Такое вообще возможно?

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

вот прям закрываешь сокеты? вот прям правильно опции установил и принудительно убиваешь? ну дык даже это гарантии не дает, смотри настройки ядра ;)

и ещераз: разберись что показывает lsof в той колонке - узнаешь много интересного.

насчет последнего предположения - технически, да, но вернее всего это не зебра и ты слишком усложняешь.

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

Дело в том что я вижу какие запросы делает приложение и следов домена deploy.static.akamaitechnologies.com нигде нет

сверь IP адреса. Например 

$ ping -c1 www.microsoft.com
PING e13678.dspb.akamaiedge.net (23.214.194.161) 56(84) bytes of data.
64 bytes from a23-214-194-161.deploy.static.akamaitechnologies.com (23.214.194.161): icmp_seq=1 ttl=53 time=90.2 ms

--- e13678.dspb.akamaiedge.net ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 90.225/90.225/90.225/0.000 ms

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

В любом случае ты просишь найти проблему, но кода мы не видим и это просто сводится к гаданию на кофейной гуще.

Как часто ты создаешь подключение к базе? Обычно такие штуки получают в достаточно редких случаях

_mysql_exceptions.OperationalError: (2004, «Can't create TCP/IP socket (24)»)

Не пробовал количество активных подключений урезать? Делать отложенные задачи через celery какой-нибудь?

Так же проверь таймауты на соединения.

deterok ★★★★★
()

В адрес a2-19-32-85.deploy.static.akamaitechnologies.com резолвится обратная запись 85.32.19.2.in-addr.arpa для IP адреса 2.19.32.85. Сертификат на 443-м порту этого адреса говорит что там обслуживаются домен san5.premiumtv.co.uk (впрочем скорее всего там же обслуживаются десятки разных доменов, если не сотни).

ei-grad ★★★★★
()

<vanga_mode>проблема в том что ты создаешь новый http-клиент на каждый запрос и не реюзаешь сессии</vanga_mode>

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

Угу, я тоже об этом подумал. И такое же впечатление о соединение с базой.

deterok ★★★★★
()
Ответ на: комментарий от ei-grad

Я это спросил к тому, что если с ним не правильно работать, то можно интересные проблемы получать. Например при обрыве соединения корутина просто завершается если ты ее не защитил от этого. Тем самым часть логики может не исполниться.

deterok ★★★★★
()
Ответ на: комментарий от ei-grad

В адрес a2-19-32-85.deploy.static.akamaitechnologies.com резолвится обратная запись 85.32.19.2.in-addr.arpa для IP адреса 2.19.32.85. Сертификат на 443-м порту этого адреса говорит что там обслуживаются домен san5.premiumtv.co.uk (впрочем скорее всего там же обслуживаются десятки разных доменов, если не сотни).

Да, я пришел к выводу, что нужно вычислять по IP. Домены вида a2-19-32-85.deploy.static.akamaitechnologies.com не дают нужной информации

taronto
() автор топика
Ответ на: комментарий от ei-grad

<vanga_mode>проблема в том что ты создаешь новый http-клиент на каждый запрос и не реюзаешь сессии</vanga_mode>

Да, я создаю новый http-клиент для каждого запроса. А о каких сессиях идет речь? Если те что в кукисах лежат, то мне они не нужны

taronto
() автор топика
Ответ на: комментарий от deterok

Это открытый проект github.com/taroved/pol Соединения к базе закрываются нармально. И сейчас ошибка с базой не проявляется. Сейчас появляется socket.error: [Errno 24] Too many open files. Это сообщение возникает при попытке подключится к memcached (т.к. к memcached-у соединение раньше, чем к Mysql идет) Т.е. речь идет о лимите открытых файлов/сокетов на уровне OS. Я думаю, что число открытых сокетов растет за счет подвешенных http запросов. Потому что ни MySQL запросы ни memcached запросы подозрений не вызывают

taronto
() автор топика
Ответ на: комментарий от deterok

Да. Я к тому что на asyncio сейчас уже обычно пишут с async/await, и таких ошибок меньше. А на twisted - на deferred'ах с callback'ами.

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

Этот проект возник до появления asyncio

taronto
() автор топика

Всем спасибо за участие в этой теме. Дело было в незакрывающихся https соединениях. Спасибо за потраченное на мой вопрос время

taronto
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Как переопределить поведение сисколов для определённого процесса?
Development
с++, nasm, массивы и деление →