Websockets proxy Nginx, conexões não fechadas

Question

Estou confuso sobre onde o problema está localizado, mas basicamente eu tenho nginx proxying conexões websocket para um servidor backend thin ruby, que atende as conexões com o módulo websocket-rails em um aplicativo Ruby on Rails. O que tudo funciona bem, exceto pelo fato de que muitos soquetes, talvez todos eles, não são fechados, então o servidor thin fica relativamente rápido sem descritores de arquivos.

Estou usando o nginx 1.4.2 e esta é minha configuração:

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;
    }
}

Estou usando o thin 1.5.1 e esta é a configuração:

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

Há apenas algumas dezenas de conexões ativas de websocket por vez, e elas parecem estabelecidas e terminadas bem na perspectiva de um navegador cliente ou do back-end websocket-rails. Mas o servidor thin acaba com 1025 descritores de arquivos abertos, principalmente soquetes.

ls -l /proc/'ps aux | grep "thin server" | grep -v grep | head -n 1 | awk '{print $2}''/fd

dá esse tipo de coisa:

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]

Uma coisa semelhante parece acontecer depois para o nginx:

ls -l /proc/'ps aux | grep "nginx: worker" | grep -v grep | head -n 1 | awk '{print $2}''/fd

embora o número de descritores de arquivo de soquete se acumule mais lentamente e demore muito mais para chegar ao 1025. De fato, eu só vi isso uma vez.

Então, estou um pouco perdido para identificar se há um problema com minha configuração nginx, ou com thin, ou algo no backend websocket-rails. Espero que alguns dos seus olhos treinados vejam algo obviamente errado, mesmo que você não esteja familiarizado com as peças de backend.

    

Answer 1

Deixe-me responder minha própria pergunta ... O que estava errado acabou sendo nada com a configuração descrita acima, o que ainda parece perfeitamente razoável.

O autor do módulo websocket-rails apontou para mim que eu estava abrindo uma nova conexão com o Redis para cada ação acionada no módulo websocket. Aparentemente, essa conexão não foi fechada corretamente, o que fez com que os soquetes abertos não fossem fechados, o que causou uma parada fina. O uso de uma conexão Redis definida e reutilizada mudou tudo.

Então, uma situação bastante obscura, e estou um pouco envergonhado por ter apresentado isso como um problema de configuração do servidor.