Nano Hash - криптовалюты, майнинг, программирование

Файлы сокетов не закрываются процессом Node

Я столкнулся со странной проблемой с нашей службой узлов.

Многие дескрипторы файлов сокета остались открытыми для процесса узла, и достигнут предел для открытых файлов (10240 файлов) для процесса. Итак, я получаю ошибку EMFILE.

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

Нигде в коде я ЯВНО не имею дело с подключениями к сокетам.

Узловой процесс все еще прослушивает порт. Мы используем PM2.

Аналогичный вопрос для Java: https://serverfault.com/questions/153983/sockets-found-by-lsof-but-not-by-netstat

Ниже приведены сведения о версиях:

  • Версия узла: 8.16.0
  • Хапи: 14.2.0
  • запрос: 2.88.2 (используется для отправки исходящих запросов)

Вывод команд в консоль:

[CONSOLE ~]$ lsof -p [PID] | wc -l
10253
[CONSOLE ~]$ ulimit -a
.
.
file size               (blocks, -f) unlimited
.
.
max memory size         (kbytes, -m) unlimited
open files                      (-n) 10240
.
.
.
[CONSOLE ~]$ netstat -np | grep [PORT]
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
[CONSOLE ~]$ netstat -a -n | grep  [PORT]
tcp        0      0 0.0.0.0:[PORT]           0.0.0.0:*               LISTEN     
[CONSOLE ~]$ lsof -i :[PORT]
COMMAND   PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
node    [PID] glpd   15u  IPv4 2270823542      0t0  TCP *:[PORT] (LISTEN)
[CONSOLE ~]$ lsof -p [PID]
COMMAND   PID USER   FD      TYPE             DEVICE SIZE/OFF       NODE NAME
.
.
.
node    [PID] glpd   15u     IPv4         2270823542      0t0        TCP *:[PORT] (LISTEN)
node    [PID] glpd   16u     sock                0,7      0t0 2271652082 protocol: TCP
node    [PID] glpd   17u     sock                0,7      0t0 2271551621 protocol: TCP
node    [PID] glpd   18u     sock                0,7      0t0 2271663118 protocol: TCP
node    [PID] glpd   19u     sock                0,7      0t0 2271662963 protocol: TCP
node    [PID] glpd   20u     sock                0,7      0t0 2271660595 protocol: TCP
node    [PID] glpd   21u     sock                0,7      0t0 2271652144 protocol: TCP
node    [PID] glpd   22u     sock                0,7      0t0 2271660631 protocol: TCP
node    [PID] glpd   23u     sock                0,7      0t0 2271662997 protocol: TCP
node    [PID] glpd   24u     sock                0,7      0t0 2271660660 protocol: TCP
node    [PID] glpd   25u     sock                0,7      0t0 2271663083 protocol: TCP
.
.
.

Кто-нибудь сталкивался с таким в Node?

РЕДАКТИРОВАТЬ:
Тайм-аут сокета для всех входящих запросов к этой службе отключен (установлен на false), поскольку это наша основная служба обработки, и мы не можем предсказать, сколько времени может потребоваться запрос для получения обработанный.

request node.js sockets hapijs
06.03.2020

  • Что делает ваш процесс? Вы на 100% уверены, что у вас нет некоторых входящих HTTP-запросов, на которые вы никогда не отправляете ответ, чтобы они оставались открытыми какое-то время? Существует ›вероятность 90%, что это что-то в вашем собственном коде, возможно, вероятность 9%, что это вызвано каким-то модулем, который вы используете, и вероятность <1%, что это общая ошибка nodejs. К вашему сведению, если вы используете библиотеку request(), каждый раз, когда вы ее вызываете, вы создаете сокет, который должен быть очищен, если все работает успешно, но его можно оставить на некоторое время в некоторых условиях ошибки. 06.03.2020
  • @ jfriend00: Я проверил то же самое с lsof и netstat, чтобы определить, зависает ли что-то в состояниях TCP ... ничего не кажется зависшим ... Вывод для этих команд добавлен для справки. 06.03.2020
  • Вы где-то протекаете дескриптором файла? 06.03.2020
  • @ jfriend00: все типы файловых дескрипторов - это sock, с которыми я не обращаюсь напрямую через свой код. 06.03.2020
  • Пересматривая ваше редактирование, ваше изложенное обоснование не имеет никакого смысла. Сколько времени вы потратите на обслуживание запроса после того, как все это у вас будет, не имеет никакого отношения к тайм-аутам сокетов на вашем сервере, которые полностью и исключительно связаны с чтением запроса. должен всегда иметь тайм-аут чтения в серверном приложении, чтобы защитить себя от недобросовестных клиентов и клиентов, которые не отправляют все запросы своевременно. В противном случае вы собираетесь накапливать утечки сокетов, и это именно то, что происходит. 06.03.2020

Ответы:


1

У меня такая же проблема. В моем случае nodemailer не закрыл соединение после transport.close (). Обновление до последней версии nodemailer решило проблему.

05.01.2021
Новые материалы
Кластеризация: более глубокий взгляд
Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
Как написать эффективное резюме
Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
Частный метод Python: улучшение инкапсуляции и безопасности
Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
Как я автоматизирую тестирование с помощью Jest
Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..