Question

I have a deployment using: rails 2.3.2 ruby 1.8.7 mysql db and 3 mongrel instances (windows services) with apache as load balancer [I know it is due for upgrade...]

OS: Windows2003

We have many CPU intensive tasks and when these occur on the 4 core machine the mongrel process is able to only use a max 25% cpu power on the core the task was scheduled. After running many tests we noticed that it is only able to use the power of a single core and therefore there is time lag in finishing tasks.

There is a suggestion to virtualize... which is difficult to do on the client server. Has anyone got any suggestion on how the situation can be improved? Memory does reach 250MB to 1GB for this process but this not such a big issue.

Thanks in advance Linus

Was it helpful?

Solution

The typically used Ruby versions (MRI or YARV, i.e 1.8 or 1.9) are not able to use more than one core at a time. MRI is single-threaded and just provides green threads internally. YARV uses real OS threads but has a GIL (global interpreter lock) that ensures that only one thread is running at a time.

Thus, your mongrels are unable to use more than one core each (even if you would have coded your Rails app to be threadsafe). There are alternative Ruby implementations, like JRuby or Rubinius that provide native threads without a global interpreter lock and thus allow your app to use more than one core, but you'd probably need to adapt your app a bit.

That said, even then a single request would run in a single thread and thus only use a single core. But that is something that is hard to come by without you handling your own threads (or at least fibers in 1.9) which is most probably not worth the hassle.

So generally, the recommendation is to start multiple app server processes (mongrels in your case). I personally use about 1.5 - 3 per core (depending on the app). That way, you are able to answer that many parallel requests and fully use your available CPU power shared between them.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top