瘦超时 Nginx 无法连接答案

【问题标题】：Thin timing out Nginx cannot connect瘦超时 Nginx 无法连接
【发布时间】：2016-03-29 15:01:36
【问题描述】：

我一直在尝试不同的配置，但无法弄清楚 Thin 超时的原因。至少这是我认为正在发生的事情。服务器闲置一段时间（即过夜）后，Thin 不可用。

环境：

在 AWS t2.nano 上运行的 Ubuntu 14.04
Redmine：Redmine 2.6.10.stable.15251
Ruby：1.9.3p484（2013-11-22 修订版 43786）[x86_64-linux]
导轨：3.2.22.2
Thin：1.3.1 代号 Triple Espresso
数据库：mysql

没有精简错误日志。 Nginx中的错误日志是：

2016/03/24 07:01:47 [错误] 18432#0: *1376 connect() to unix:/ebs_001/redmine/run/thin/redmine.0.sock 失败（111：连接被拒绝）而连接上游，客户端：184.166.153.12，服务器：pm.source3.com，请求：“GET / HTTP/1.1”，上游：“http://unix:/ebs_001/redmine/run/thin/redmine.0.sock:/”，主机：“pm.source3.com”

我可以重新启动 Thin（稍后会详细介绍）并在不重新启动 Ngnix 的情况下进行连接。

当我尝试停止 Thin 时，我收到以下消息

user1@ip-172-31-18-58:/var/log/nginx$ sudo service thin stop

[stop] /etc/thin1.9.1/redmine.yml ...
Stopping server on /ebs_001/redmine/run/thin/redmine.0.sock ... 
Sending QUIT signal to process 18385 ... 
process not found!
Sending KILL signal to process 18385 ... 
/usr/lib/ruby/vendor_ruby/thin/daemonizing.rb:140:in `kill': No such         process (Errno::ESRCH)
    from /usr/lib/ruby/vendor_ruby/thin/daemonizing.rb:140:in `force_kill'
    from /usr/lib/ruby/vendor_ruby/thin/daemonizing.rb:134:in `rescue in send_signal'
    from /usr/lib/ruby/vendor_ruby/thin/daemonizing.rb:118:in `send_signal'
    from /usr/lib/ruby/vendor_ruby/thin/daemonizing.rb:107:in `kill'
    from /usr/lib/ruby/vendor_ruby/thin/controllers/controller.rb:93:in `block in   stop'
    from /usr/lib/ruby/vendor_ruby/thin/controllers/controller.rb:134:in `tail_log'
    from /usr/lib/ruby/vendor_ruby/thin/controllers/controller.rb:92:in `stop'
    from /usr/lib/ruby/vendor_ruby/thin/runner.rb:185:in `run_command'
    from /usr/lib/ruby/vendor_ruby/thin/runner.rb:151:in `run!'
    from /usr/bin/thin:6:in `<main>'

在我停止 Thin 之后，我可以启动 Thin（sudo service Thin start）并连接到我的 redmine 项目，而无需重新启动 nxinx。我在 redmine 或 Thin 中看不到任何错误日志。

我的 /etc/thin/redmine.yml 文件：

---
user: user1
group: group1
pid: /ebs_001/redmine/run/thin/redmine.pid
timeout: 30
wait: 30
log: /ebs_001/redmine/logs/thin/redmine.log
max_conns: 1024
require: []
environment: production
max_persistent_conns: 512
servers: 1
daemonize: true
socket: /ebs_001/redmine/run/thin/redmine.sock
chdir: /ebs_001/redmine/redmine-2.6
tag: redmine

我的 /etc/nginx/sites-available/redmine.conf 的一部分：

# Upstream Ruby process cluster for load balancing
upstream thin_cluster {
    server unix:/ebs_001/redmine/run/thin/redmine.0.sock;
    # server unix:/ebs_001/redmine/run/thin/redmine.1.sock max_fails=1     fail_timeout=15s;
    # server unix:/ebs_001/redmine/run/thin/redmine.2.sock;
    # server unix:/ebs_001/redmine/run/thin/redmine.3.sock;
}

### REDMINE - serve all pages via ssl (https)

server {
    listen 80;
    server_name pm.source3.com;
    return 301 https://$host$request_uri;
}

server {
    listen       443 ssl;
    server_name  pm.source3.com;
    ssl on;
    ssl_certificate /etc/nginx/ssl/redmine.crt;
    ssl_certificate_key /etc/nginx/ssl/redmine.key;

    include /etc/nginx/includes/redmine.include;
    proxy_redirect off;
    root   /ebs_001/redmine/redmine-2.6;

    # An alias to your upstream app
    location @cluster {
        proxy_pass http://thin_cluster;
        # Define what a "failure" is, so it can try the next server
        proxy_next_upstream error timeout http_502 http_503;
        # If the upstream server doesn't respond within n seconds, timeout
        proxy_read_timeout 60s;
    }    

    location / {
        try_files $uri/index.html $uri.html $uri @cluster;
    }
}
...

还有../includes/redmine.include

proxy_set_header   Host $http_host;                                                                                          
proxy_set_header   X-Real-IP $remote_addr;                                                                                   
proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header   X-Forwarded-Proto $scheme;

client_max_body_size       10m;
client_body_buffer_size    128k;

proxy_connect_timeout      90;
proxy_send_timeout         90;
proxy_read_timeout         90;

proxy_buffer_size          4k;
proxy_buffers              4 32k;
proxy_busy_buffers_size    64k;
proxy_temp_file_write_size 64k;

这不是权限问题，因为我可以重新启动 Thin 并连接到 Redmine。

我只有大约 15M 的可用内存。也许这就是问题所在。但如果是这样的话，Redmine 会因为我一整天都在使用它而崩溃。

非常感谢任何有关确定超时的帮助。最后，我尝试使用端口而不是套接字，但仍然遇到同样的超时问题

【问题讨论】：

标签： nginx redmine thin

【解决方案1】：

问题是服务器内存不足。我在 AWS t2.nano 上运行了许多应用程序。 Redmine是唯一一个崩溃的。没有错误日志暗示这是内存问题。 “free -h”命令是一个很大的线索。

我在跑步：

一个 Django 应用程序（针对 AWS RDS 运行 Postgres）
WordPress
Redmine（在本地运行 MySQL）。

迁移到 AWS t2.mircro 以获得更多内存，一切都很好。

【讨论】：