Наше приложение стало безразличным при высоких загрузках с более длительными временами ожидания. Использование процесса было неправильно низким (загрузка ЦП для каждого процесса на ~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, ай!Должен был разбудить приложение, таким образом, временное решение:
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
Мои вопросы:
TIME-WAIT
состояние?Заранее спасибо за любую справку можно предложить!
В конце концов, я провел дополнительные исследования и прочитал это отличное руководство по масштабированию приложений Node за прокси-сервером nginx.
Существенная разница возникла, когда я добавил параметр keepalive
для восходящего блока
в nginx. Оказывается, рабочие nginx не кэшируют входящие соединения и не используют их повторно, что приводит к созданию многих тысяч новых соединений (особенно с рукопожатием с socket.io и т. Д.)
@ Предложение Майкла Хэмптона об использовании unix сокет домена также может решить эту проблему.