Высокий # сокетов в СОСТОЯНИИ ОЖИДАНИЯ ВРЕМЕНИ, сервера, безразличного при загрузке

Наше приложение стало безразличным при высоких загрузках с более длительными временами ожидания. Использование процесса было неправильно низким (загрузка ЦП для каждого процесса на ~15%, наше выполнение приложения на 8 процессах).

Вывод журнала ошибок Nginx показал много они:

2014/12/04 03:39:31 [crit] 24383#0: *2008067 connect() to 127.0.0.1:4567 failed (99: Cannot assign requested address) while connecting to upstream, client: 108.162.246.229, server: example.org, request: "GET /socket.io/?EIO=3&transport=polling&t=1417682366937-11501 HTTP/1.1", upstream: "http://127.0.0.1:4567/socket.io/?EIO=3&transport=polling&t=1417682366937-11501", host: "example.org", referrer: "https://example.org/unread"

Что я видел

  • Вывод ss -tan | grep TIME-WAIT | wc -l был где-нибудь в районе 30 000, ай!
  • Приложение было бы быстро реагирующим, и затем:
    • Все процессы внезапно были бы выпадающий приблизительно к 0 использованиям ЦП
    • Приложение стало бы безразличным
    • После ~30 секунд приложение вернулось бы, повторение до бесконечности

Должен был разбудить приложение, таким образом, временное решение:

  • echo 28000 65535 > ip_local_port_range (MongoDB работает 27101, таким образом, я выбрал нижний предел выше этого),
  • echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
  • echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle

Это уменьшило # сокетов в TIME-WAIT заявите более managable ~400.


Вот отрывок ss -tan | grep TIME-WAIT:

State      Recv-Q Send-Q        Local Address:Port          Peer Address:Port
TIME-WAIT  0      0                 127.0.0.1:29993            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:28522            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:29055            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:31849            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:32744            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:28304            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:34858            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:36707            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:34756            127.0.0.1:4567  
TIME-WAIT  0      0            104.131.91.122:443          108.162.250.6:55549 
TIME-WAIT  0      0                 127.0.0.1:32629            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:34544            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:34732            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:33820            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:33609            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:34504            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:32463            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:35089            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:30003            127.0.0.1:4567  
TIME-WAIT  0      0            104.131.91.122:443         199.27.128.100:36383 
TIME-WAIT  0      0                 127.0.0.1:33040            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:34038            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:28096            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:29541            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:30022            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:31375            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:29827            127.0.0.1:4567  
TIME-WAIT  0      0                 127.0.0.1:29334            127.0.0.1:4567  

Мои вопросы:

  • Многие из них от 127.0.0.1 до 127.0.0.1, действительно ли это нормально? Адреса однорангового узла не должны все быть от внешнего дюйм/с?
    • Наше приложение Node.js находится позади прокси nginx позади CloudFlare DNS, это ограничивает количество уникальных входящих IP-адресов, это могло быть связано?
  • Как я правильно сокращаю количество сокетов в TIME-WAIT состояние?
  • Я положителен, что у нас нет 3 000 уникальных сокетных соединений в секунду, что-то неправильно конфигурируется с нашей стороны и открывающиеся сотни сокетов, когда это должно открывать тот?

Заранее спасибо за любую справку можно предложить!

4
задан 4 December 2014 в 21:18
1 ответ

В конце концов, я провел дополнительные исследования и прочитал это отличное руководство по масштабированию приложений Node за прокси-сервером nginx.

Существенная разница возникла, когда я добавил параметр keepalive для восходящего блока в nginx. Оказывается, рабочие nginx не кэшируют входящие соединения и не используют их повторно, что приводит к созданию многих тысяч новых соединений (особенно с рукопожатием с socket.io и т. Д.)

@ Предложение Майкла Хэмптона об использовании unix сокет домена также может решить эту проблему.

2
ответ дан 3 December 2019 в 03:57

Теги

Похожие вопросы