Nginx прокси веб-сокеты, соединения не закрыты
Я запутался в том, где находится проблема, но в основном у меня есть nginx, передающий соединения websocket к внутреннему тонкому серверу ruby end, который обслуживает соединения с модулем websocket-rails в приложении Ruby on Rails. Все это прекрасно работает, за исключением того, что многие сокеты, может быть, все они не закрываются, поэтому на тонком сервере относительно быстро заканчиваются файловые дескрипторы.
Я использую nginx 1.4.2, и это мой конфиг:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen my.ip.num.ber:80;
server_name admin3.mydomain.com;
root /home/apps/mydomain/current/public;
try_files $uri/index.html $uri @admin3.mydomain.com;
access_log /var/log/nginx/admin3.access.log combined;
error_log /var/log/nginx/admin3.error.log error;
location /websocket {
proxy_redirect off;
proxy_pass http://localhost:3008;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
keepalive_timeout 90;
proxy_connect_timeout 10;
proxy_read_timeout 60;
proxy_send_timeout 60;
}
}
Я использую тонкий 1.5.1, и это конфигурация:
port: 3008
user: ploy
group: ploy
pid: /home/apps/mydomain/shared/pids/thin.pid
timeout: 90
wait: 30
log: /home/apps/mydomain/shared/log/thin.log
max_conns: 1024
require: []
environment: production
max_persistent_conns: 512
servers: 1
threaded: false
#no-epoll: false
daemonize: true
chdir: /home/apps/mydomain/current
tag: admin3
Есть только пара дюжин активных подключений к веб-сокетам, и они, кажется, установлены и нормально разрываются с точки зрения клиентского браузера или серверной части веб-сокетов. Но тонкий сервер заканчивается 1025 открытыми файловыми дескрипторами, в основном сокетами.
ls -l /proc/`ps aux | grep "thin server" | grep -v grep | head -n 1 | awk '{print $2}'`/fd
дает такую вещь:
lrwx------. 1 root root 64 Aug 31 15:15 993 -> socket:[1319549665]
lrwx------. 1 root root 64 Aug 31 15:15 994 -> socket:[1319549762]
lrwx------. 1 root root 64 Aug 31 15:15 995 -> socket:[1319549850]
lrwx------. 1 root root 64 Aug 31 15:15 996 -> socket:[1319549974]
lrwx------. 1 root root 64 Aug 31 15:15 997 -> socket:[1319846052]
lrwx------. 1 root root 64 Aug 31 15:15 998 -> socket:[1319549998]
lrwx------. 1 root root 64 Aug 31 15:15 999 -> socket:[1319550000]
Похоже, что подобное впоследствии происходит с nginx:
ls -l /proc/`ps aux | grep "nginx: worker" | grep -v grep | head -n 1 | awk '{print $2}'`/fd
хотя число дескрипторов файлов сокетов увеличивается медленнее, и до 1025 уходит намного больше времени. На самом деле, я видел это только один раз.
Итак, я немного затрудняюсь определить, есть ли проблема с моим конфигом nginx, или с thin, или с чем-то в бэкэнде websocket-rails. Я надеюсь, что некоторые из ваших тренированных глаз могут увидеть что-то явно не так, даже если вы не знакомы с бэкэндом.
1 ответ
Позвольте мне ответить на мой собственный вопрос... То, что было неправильно, оказалось ничего не значащим с конфигурацией, изложенной выше, которая все еще кажется совершенно разумной.
Автор модуля websocket-rails указал мне, что я открываю новое соединение с Redis для каждого действия, запускаемого в модуле websocket. Очевидно, что это соединение не было закрыто должным образом, что привело к тому, что открытые розетки не были закрыты, и привело к остановке тонких деталей. Использование соединения Redis, установленного один раз и использованного повторно, изменило все.
Итак, довольно непонятная ситуация, и мне немного стыдно даже представить ее как проблему конфигурации сервера.