Ruby on Rails Friday, August 30, 2013

FIXED
I had the restart_command in puma.rb trying to run 'puma.sock restart', I pointed it to my init.d file and it no longer has an issue when it boots workers

restart_command '/etc/init.d/puma restart'

I still occasionally get a 504 timeout under very heavy load, but i have the god gem monitoring too and it recovers from that quickly




On Thursday, August 29, 2013 5:51:24 PM UTC-4, Rob Daniels wrote:
I'm having an issue with Puma, it fails when it tries to restart itself. When this happens it kills all the Puma processes, resulting in nginx delivering a 502 Bad Gateway to our users. I'm able to start, stop & restart it with my /etc/init.d/puma script (it runs /usr/local/bin/run-puma),  it just has issues when it restarts itself. The puma.log file doesn't show anything just useful for troubleshooting, just

Puma starting in single mode...
* Version 2.5.1, codename: Astronaut Shoelaces
* Min threads: 16, max threads: 32
* Environment: production
* Listening on unix:///home/deploy/app/shared/sockets/puma.sock

and my workers. Any help would be greatly appreciated.

Also - i have whats probably a pretty dumb question. Is there a way for me to allocate more resources to Puma so it doesn't need to restart itself so frequently? I'm currently only using around 25% of the server's memory.

Thanks for the help

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/57281308-5f55-49ce-bec3-2a06a6e9c592%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

No comments:

Post a Comment