Alex Sharp <[email protected]> wrote:
> On Thu, Aug 4, 2011 at 9:09 PM, Alex Sharp <[email protected]> wrote:
> > On Tue, Aug 2, 2011 at 2:54 PM, Eric Wong <[email protected]> wrote:
> >> Can you try to strace (or equivalent) the old master to see what's using
> >> 100% CPU?
> >>
>
> Actually, my fault -- the last email was the output of new master.
> Running strace on the old master shows the following:
Is this Unicorn 3.x? Which 3.x version exactly? Maybe give 4.0.1
or the 4.0.2 git prerelease a try, too.
> select(4, [3], NULL, NULL, {13, 466686}) = 0 (Timeout)
> wait4(-1, 0x7fff57e7bfcc, WNOHANG, NULL) = 0
> clock_gettime(CLOCK_REALTIME, {1312517345, 425411398}) = 0
> fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
> clock_gettime(CLOCK_REALTIME, {1312517345, 425625251}) = 0
> fstat(11, {st_mode=S_IFREG, st_size=0, ...}) = 0
> clock_gettime(CLOCK_REALTIME, {1312517345, 425779281}) = 0
> fstat(12, {st_mode=S_IFREG, st_size=0, ...}) = 0
> clock_gettime(CLOCK_REALTIME, {1312517345, 425927762}) = 0
Can I get more? (until the next select() call, at least). I'd like to
see the timeout argument that gets passed to the next select().
If you see select() with very small timeout, use "strace -v" to get the
st_ctime from fstat()s...
I could have a math bug in murder_lazy_workers (please read/review the
logic in that method, I haven't noticed issues myself).
I made some tweaks to the master sleep strategy within the past year to
reduce wakeups during idle hours. This is intended to go with Ruby
1.9.3 which will have /much/ better thread wakeup strategy that reduces
power consumption during idle times.
> The first line was when the master was idle, and then I threw a few
> requests at it.
Are all workers responding as expected and not dying?
--
Eric Wong
_______________________________________________
Unicorn mailing list - [email protected]
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
