Hacker News Reader

Comment by joevandyk | Hacker News Reader

You run "touch #{RAILS_ROOT}/tmp/restart.txt".

That will restart the rails processes. No connections are dropped, and I've not seen any downtime.

To clarify, my understanding is that while rails is restarting, Passenger will queue all the requests that come in and begin processing them as soon as rails is ready. But yeah, zero downtime, it's pretty awesome.

that is correct.

Sites do tend to lag for at least several seconds after the restart though.

Yeah. We load balance across 5 Apache/Passengers and I do rolling deploys (all in Capistrano) by removing a Passenger from load balancing, updating the app, restarting Apache, and adding it back into load balancing with a 10 second delay between each. We tried the Passenger touch restart.txt and that didn't go well at all when we were under load.

Have you tried contacting the Passenger developers about this? I won't be surprised if they come out with a fix for this.

Can you share your setup please?

He has been kind enough to share about his setup quite a lot about lately. In fact, looks like it's on the HN homepage right now: http://news.ycombinator.com/item?id=872301

I wrote a short post about our setup in March and it hasn't really changed since then: http://codemonkey.ravelry.com/2009/03/10/quick-update-ravelr...

If you have any questions or are looking for details or something, ask away - just stick a comment on the blog post.

Also, if you're using Monit to watch the memory bloat of your passenger processes, when you kill one process it tends to do the same stalling thing on all your processes until the ONE you killed is back up.

Reply on news.ycombinator.com