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, установленного один раз и использованного повторно, изменило все.

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

Другие вопросы по тегам