2016-03-29 4 views
0

私はさまざまな構成を試してきましたが、なぜシンがタイムアウトしているのか理解できません。少なくともこれは私が起こっていると思います。サーバーがしばらくアイドル状態になってから(つまり、夜間に)シンが使用できなくなります。 AWSにt2.nano シン・タイムアウト・アウトNginxは接続できません

  • 記法実行

    • Ubuntuの14.04:環境

      記法を2.6.10.stable.15251

    • ルビー:1.9.3p484(2013年11月22日改訂43786) [x86_64版-linuxの]
    • のRails:3.2.22.2
    • シン:1.3.1コードネームトリプルエスプレッソ
    • データベース:MySQLの

    いいえシンエラーログ。 nginxの中のエラーログがある:UNIXへ* 1376は、(接続):

    2016年3月24日7時01分47秒[エラー] 18432#0 /ebs_001/redmine/run/thin/redmine.0サーバー:pm.source3.com、要求:「GET/HTTP/1.1」、上流:「http://unix:/ebs_001/redmine/run/thin/redmine.0.sock:/」、ホスト:「pm.source3」)。 .com "

    Thinを再起動して、Ngnixを再起動せずに接続することができます。

    私はシン停止しようとすると私はシン停止した後、私はその後、シン(sudoのサービスシン開始)を開始し、nxinxを再起動せずに私のRedmineのプロジェクトに接続することができ、次のメッセージ

    [email protected]:/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>' 
    

    を取得します。 redmineまたはThinにエラーログが表示されません。

    マイ/etc/thin/redmine.ymlファイル:私の/etc/nginx/sites-available/redmine.confの

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

    一部:

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

    そして../含まれている/ 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は私が一日中使っているのでクラッシュするでしょう。

    タイムアウトを把握するための助けがあれば大歓迎です。最後に、ソケットではなくポートを使用しようとしましたが、同じタイムアウトの問題がありました。

  • 答えて

    0

    問題はサーバー上で不足していました。私はAWS t2.nanoで多くのアプリケーションを実行していました。レッドマインだけが墜落した。エラーログにはメモリ上の問題点はありませんでした。そして、 "自由な"コマンドは大きなヒントでした。

    私は走っていた:

    1. 一つのDjangoアプリ(PostgresのVIS AWS RDSを実行している)
    2. ワードプレス(ローカルのMySQLを実行している)
    3. Redmineの。

    さらに多くのメモリをAWS t2.mircroに移行しても問題ありません。