My misbehaving Rails application

My number one point of frustration with Ruby on Rails is that as easy it as it is to build Rails applications, it’s a big challenge to get them deployed properly (mainly due to lacking documentation for Capistrano) and to keep them running happily.

I have a simple Rails application that I’ve deployed using Apache and Mongrel, with three Mongrel processes. When I looked at top this morning (it had been running awhile), it was consuming over 500 megs of RAM. My first thought was, of course, “memory leak”. I restarted the app, and the ”mongrel_rails” process was consuming only 32 megs of RAM. I’ve since watched it grow to 45 megs of RAM consumed. That appears to confirm my suspicion that something is leaking memory.

What’s next? Finding the memory leak. The problem could be a bug in Ruby, Mongrel, the Ruby on Rails gems, any other gem I’m using, or my code itself. At this point I need to sift through the next steps and start experimenting. The options from here are:

1. Start upgrading pieces of infrastructure for which new versions are available.
2. Instrument the application and try to figure out what’s leaking memory.
3. Try to reproduce the problem locally so that I can experiment in a safe environment.

I’ll let you know how it works out.

While I enjoyed developing this application using Ruby on Rails, the amount of infrastructure required to keep this relatively simple application up and running frustrates me a bit. Had I written this application in PHP, I might have two dozen files in a directory running under the versions of Apache and PHP that were bundled with the server’s Linux distribution. The odds of running into a memory leak in that kind of environment are really low, especially with an application as simple as the one I’m dealing with.

With Ruby on Rails and its relatively immature infrastructure, the administrative overhead is higher than it would be for many other types of applications. The complexity of the Ruby on Rails infrastructure also explains why Ruby on Rails is unsuitable for shared hosting.

The takeaway from this is that there’s more than speed of development to take into account if you’re deciding whether to use Ruby on Rails to build an application. You also need to determine whether you have the administrative cycles you need for the care and feeding of a Ruby on Rails application.

Update: The first thing I did was upgrade Rails from version 1.2.3 to 1.2.6. We’ll see what effect that has on the memory leak.