Skip to content

Queue Wait Spikes with Passenger and NewRelic

So I’ve been struggling with “Queue Wait” spikes on NewRelic. I think I have pretty much determined that the spikes are caused by Passenger spinning up new threads to handle additional requests. Here’s what I did.

First I restarted my app, and let it run for a bit, then I used “passenger-status” to see what the threads were doing:

----------- General information -----------
max      = 30
count    = 3
active   = 0
inactive = 3
Waiting on global queue: 0

----------- Domains -----------
  PID: 9734    Sessions: 0    Processed: 48      Uptime: 18m 54s
  PID: 9704    Sessions: 0    Processed: 49      Uptime: 19m 5s
  PID: 9706    Sessions: 0    Processed: 57      Uptime: 19m 2s

I’d basically just run it again every few minutes to see what was happening, and then I got this:

----------- General information -----------
max      = 30
count    = 4
active   = 0
inactive = 4
Waiting on global queue: 0

----------- Domains -----------
  PID: 9822    Sessions: 0    Processed: 34      Uptime: 4m 57s
  PID: 9706    Sessions: 0    Processed: 103     Uptime: 26m 43s
  PID: 9704    Sessions: 0    Processed: 107     Uptime: 26m 46s
  PID: 9734    Sessions: 0    Processed: 75      Uptime: 26m 35s

Mon May 17 13:54:20 MDT 2010

(I actually started running passenger-status; date so I could have the time I ran the command). The above tells us that at roughly 13:49 Passenger spun up another thread. Refreshing NewRelic, I saw this:

I spent more time investigating, and it does seem that the queue wait spikes, roughly correspond to times that Passenger starts more threads.

Posted in Rails, Ruby, Software Development.

Tagged with , , , .

3 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. Nicolás Mery says

    Hi, have you resolved this issue? I too have this “queue spikes” on my newrelic logs


  2. jtanium says

    No I haven’t. If there was a “minimum pool size” directive for Passenger, then you could crank it up so there would always be X number of threads running and you wouldn’t get the spikes very often.

    I suppose if you don’t care about resources, you could up the PassengerPoolIdleTime and PassengerMaxRequests directives so your threads run longer, that would decrease the need for Passenger to spawn a new thread. I might actually give that a try.

  3. Josh says

    Coming to this post late, so you may not need this info anymore. Passenger 3 does not block all other requests when spawning new workers, so updating may smooth this out.

Some HTML is OK

or, reply to this post via trackback.