Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a Spree site running the following stack:

  • Nginx 1.0.8
  • Passenger 3.0.9
  • Ruby 1.9.2-p290
  • Rack 1.3.6
  • Rails 3.1.4
  • Spree 0.70.5

I recently upgraded from Spree 0.70.3, which also brought a Deface upgrade from 0.7.x to 0.8.0. Since then things have been very unstable.

Recently we've seen some CPU-hogging processes which drive load up on the server and grind the whole thing to a stop. They're Rack processes and it looks like Passenger is starting them; they're owned by the site-runner user, an unprivileged user who owns the application code. (Passenger automatically runs the site code as the user who owns it.) If I restart Nginx and kill the runaway processes, it helps for a while, but eventually similar processes return and bog things down again.

ETA: I'm looking now at passenger-status and passenger-memory-stats which suggest these are Passenger's application processes. If it's running away or hanging, there must be an issue with my app.

What's my best option for figuring out where this is hanging?

share|improve this question

1 Answer 1

up vote 1 down vote accepted

Rack processes are the application servers running your site code not Passenger. I'd suspect problems with the recent upgrades and all the usual troubleshooting around that. Here's what a request looks like on your system.

user -> nginx -> passenger -> Rack process -> generates page

You system will have multiple Rack processes because each is single threaded and can only handle one request at a time. Passenger's job is to proxy requests and send them to Rack processes and start/stop/recycle those Rack processes as needed. Generally a Rack process will take 5-45 seconds to start depending on the complexity of your app so you'll usually have a few running even when not serving requests.

share|improve this answer
    
Thanks. We tracked the problem down to a database integrity issue; some requests were being made for a resource that no longer existed, and for complicated reasons it wasn't returning a 404 when it should have. –  pjmorse Mar 21 '12 at 14:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.