This is linux specific. The following command retrieves the memory:

memory_usage = `ps -o rss= -p #{$$}`.to_i

The reason I created this was to help track down a memory leak. It worked very well because it adds the process id and memory usage in with EVERY single line logged and at the end of each rails request. By every line, I mean every line in your log will end with “ (mem #{memory_usage})”.

This way, if you have a cluster, you can monitor each process and scroll through your logs and watch the memory. If it suddenly starts to jump you can look at the request and at least you have a starting point. You can checkout the code for that specific controller action and try to narrow it down.

Please note this is only for doing research. There is a cost to finding the current memory usage on every log output. The average cost is probably in the realm of 20ms per execution. Which means an extra 20ms every time a line is logged.

Open up your log in a program that is made to read large files, NOT textmate. The console on the mac is a great program for this. To track a process id just do a “find next” with that process id. Watch the memory as you do this, if you have a true leak it will either gradually increase and never stop, or jump all at once. This will help you pin point the type of requests increasing your memory.

A great tool for hammering your server to find the memory leak yourself is the apache benchmarking tool. It should come pre-installed on your mac. Do something like:

ab -kc 10 -t 10 http://127.0.0.1:3000/

The above will create 10 threads to hammer your server for 10 seconds as fast as they can. This will go crazy, so be careful. If you have a bad memory leak this will consume your memory in no time. If you know your memory leak is bad, try starting out with something smaller, such as 2 seconds.

Lastly, if you notice your memory gradually increasing with each request, chances are it is something global in your application, such as a before_filter in your ApplicationController. Try eliminating global things until the leak goes away. If your memory leak is very abrupt, then you are lucky, because it should be easy to pinpoint. Again try changing or removing things in that specific action to see if that removes the leak.

If you are still lost and can’t seem to pinpoint the problem, your best bet might be to create an entirely new app and move things over one by one until you can reproduce the leak. I know this is a pain in the ass, but sometimes it is the only way. It might take you a couple of hours, but you will find it. I’ve had my fair share of finding memory leaks and this method has yet to fail me.

Another tool you might find useful is: github.com/noahd1/oink/tree/master

It parses your logs and helps you find the problem in your logs. If your log is huge, this should be a quicker solution than manually searching your logs.

class Applicationcontroller
  include Memorylogic
end

Copyright © 2008 Ben Johnson of [Binary Logic](www.binarylogic.com), released under the MIT license