Question

我一直在尝试不同的配置，无法弄清楚为什么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]
Rails：3.2.22.2
薄：1.3.1代号Triple Espresso
数据库：mysql

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

2016/03/24 07:01:47 [错误] 18432＃0：* 1376 connect（）到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的情况下进行连接。

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

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（sudo服务瘦启动）并连接到我的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会在我全天使用它时崩溃。

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

Answer 1

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

我在跑步：

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

迁移到AWS t2.mircro以获得更多内存，一切正常。

精简超时Nginx无法连接

1 个答案: