Thanks Eric, I had expected that to be the case (we are under light load as of now).
On Tue, May 31, 2011 at 10:48 AM, Eric Wong <[email protected]> wrote: > Clifton King <[email protected]> wrote: >> We experience the same problem. I believe the problem has more to do >> with the kernel CPU scheduler than anything else. If you figure put a >> reliable way to spread the load, I'd like to hear it. > > Load not being spread is /not/ a problem unless there are requests that > get stuck in the listen queue. > > If no requests are actually stuck in the queue (light load), the kernel > is right to put requests into the most recently used worker since it can > get better CPU cache behavior this way. > > > == The real problem > > Under high loads (many cores, fast responses), Unicorn currently uses > more resources because of non-blocking accept() + select(). This isn't > a noticeable problem for most machines (1-16 cores). > > Future versions of Unicorn may take advantage of /blocking/ accept() > optimizations under Linux. Rainbows! already lets you take advantage > of this behavior if you meet the following requirements: > > * Ruby 1.9.x under Linux > * only one listen socket (if worker_connections == 1 under Rainbows!) > * use ThreadPool|XEpollThreadPool|XEpollThreadSpawn|XEpoll > > I haven't had a chance to benchmark any of this on very big machines so > I have no idea how well it actually works compared to Unicorn, only how > well it works in theory :) > > > Blocking accept() under Ruby 1.9.x + Linux should distribute load evenly > across workers in all situations, even in the non-busy cases where load > distribution doesn't matter (your case :). > > [1] - http://rainbows.rubyforge.org/Rainbows/XEpollThreadPool.html > > -- > 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 > _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
