On Thu, Aug 18, 2011 at 6:53 PM, Eric Wong <[email protected]> wrote: > I can see that from select() timing out despite being called with > long intervals. I don't see workers dying, either...
That's correct, the old workers are staying alive as well. > Can you add "-f -e '!futex'" to the strace invocation so we see > all the threads? You can also add '-T' to get timing information > to see how long each syscall takes or '-tt' to get timestamps > in strace if you think it's useful. > > Also, I assume you're using preload_app? If you are, do you see this > issue with preload_app=false? I suspect there's some background thread > that could be running in the master process taking up all the CPU time. > Unicorn itself never spawns background threads. Yes, we're using preload_app=true. I haven't tried it with preload_app=false -- if I get to it tomorrow I'll report back here. We *are* using newrelic, which operates in a background thread. I've just found this ticket in the newrelic support forums: https://support.newrelic.com/help/discussions/support/7692-newrelic_rpm-gem-with-unicorn-40. I'll re-run strace with the suggested flags above and report back. > Basically anything you can tell use about the app, the configuration, > and which gems/libraries would be useful. Gemfile: https://gist.github.com/05a9445471ad7edfdcb7 > OK. I wouldn't rule out the CPU usage as unrelated to the signaling > issue, though. The Ruby 1.9 timer thread could be going crazy > because it can't signal or receive signals properly... -- alex sharp github.com/ajsharp twitter.com/ajsharp alexjsharp.com _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
