RubyJudo

Apparently there is a hub-bub going around about the “multi-core crisis.” I wasn’t aware of any crisis until DHH let us know there was nothing to worry about. But unfortunately, I disagree. There’s no crisis, but there is work to be done.

Threading matters in Rails for one reason: memory.

At Agora, we have serious problems with Rails processes consuming large amounts of memory—both on start-up and leaking memory per request. While we do try to fix these problems, we still have monit restart the processes once they hit a particular amount of memory.

One such project’s cutoff is 200 MB per process. On a four-core system where you should run at least four processes, this means that one project will consume up to 800 MB on the system. If the number of cores continue to multiply, soon we will run out of memory. Adding memory to the system works, but only to a point. If you want that system to be able to run multiple Rails projects, this problem gets out of hand quickly. I have to wonder how shared hosts address this.

The alternative is threading. We would love to be able to have to monitor only a single process consuming at most 200 MB. Memory leaks aside, a newly started Rails process uses 60 to 70 MB per process. The contents of that memory could easily be shared across threads—RHTML caches, the Rails libraries, etc.

However, this is not something that Rails can do very effectively right now. Sure, Rails should be thread-safe, doing so would already be useful, but only to a point. Until Ruby implements kernel-level threads, none of this really matters. You can’t use multiple cores, and hence effectively replace multiple process, using Ruby’s current green thread implementation.