Re: Strange quit behavior

[Alex Sharp <ajsharp@gmail.com>]

On Thu, Aug 18, 2011 at 6:53 PM, Eric Wong <normalperson@yhbt.net> 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 - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying