Ich habe einen Puma-Server, der eine Ruby on Rails-App auf einer AWS EC2-Instanz ausführt. Es funktionierte für eine Weile gut, aber ich fand es ein paar Stunden später mit 502 Fehlern. Die App wird mit Capistrano bereitgestellt.Puma stiller Absturz mit Nginx Reverse Proxy
Ein einfacher Neustart von Puma behebt das Problem vorübergehend, aber ich möchte verhindern, dass es wieder passiert. Nicht ganz sicher, was ich zuerst versuchen soll.
Hier ist meine Capistrano puma config:
set :puma_rackup, -> { File.join(current_path, 'config.ru') }
set :puma_state, "#{shared_path}/tmp/pids/puma.state"
set :puma_pid, "#{shared_path}/tmp/pids/puma.pid"
set :puma_bind, "unix://#{shared_path}/tmp/sockets/puma.sock"
set :puma_conf, "#{shared_path}/puma.rb"
set :puma_access_log, "#{shared_path}/log/puma.error.log"
set :puma_error_log, "#{shared_path}/log/puma.access.log"
set :puma_role, :app
set :puma_env, fetch(:rack_env, fetch(:rails_env, 'production'))
set :puma_threads, [0, 8]
set :puma_workers, 0
set :puma_worker_timeout, nil
set :puma_init_active_record, true
set :puma_preload_app, false
set :bundle_gemfile, -> { release_path.join('Gemfile') }
Puma Fehlerprotokoll zeigt keine Abstürze.
Nginx Fehlerprotokoll zeigt (xx aus Client-IP): 2016/08/09 06:25:52 [Fehler] 1081 # 0: * 348 connect() zu unix: /// home/deploy/myapp/shared/tmp/sockets/puma.sock ist fehlgeschlagen (111: Verbindung abgelehnt), während die Verbindung zum Upstream hergestellt wurde, Client: xx.xx.xx.xx, Server: example.com, Anforderung: "POST/mypath HTTP/1.1", stromaufwärts: "http://unix:///home/deploy/myapp/shared/tmp/sockets/puma.sock:/mypath", host: "beispiel.com"
Haben Sie keine offenen Dateien mehr? (Netzwerkverbindung ist auch eine Datei) Was 'ls/proc//fd | wc -l' und 'cat/proc//limits' zeigt? –
Vasfed
@Vasfed 'ls/proc/2522/fd | wc -l'> 15 'cat/proc/2522/limits'> Max. geöffnete Dateien 1024 4096 Dateien – CaptainStiggz