On the Edge, Part 2 – New RailsLab episode in our Scaling Rails series shows plugins for detecting memory bloat

A new Scaling Rails episode is up on RailsLab. Gregg Pollack is back with part 2 in a three part series called “On the Edge,” in which he looks at some new libraries for scaling Rails. In this episode, Gregg takes a look at some Rails plugins designed to help prevent memory bloat. What is memory bloat? Gregg recommends taking a look at a recent post by Sudara Williams on the Engine Yard blog to learn about the difference between a memory leak and memory bloat. The first tool for preventing bloat is ‘rack-bug,’ a debugging toolbar for Rack apps implemented by middleware. After a tiny bit of configuration, the plugin is ready to use for checking variables such as response time for an action, and total CPU time; environment variables such as session and cookies; the queries the action ran and how they were triggered; how many Active Record objects were instantiated for the action; as well as what caching was used, and what templates were used. Finally, it shows how much RAM is used and the delta between the time the request came in and was completed.

The next plugin, ‘memorylogic,’ adds process ID and memory usage to your Rails logs. After you install the plugin, when you look at your log files you can see the memory usage at each step of a process. If you see a dramatic increase at a particular step, then you have a pretty good clue as to where memory bloat is occurring. It also shows overall memory usage and the process ID. The last library Gregg shows us is ‘oink.’ This plugin parses logs to help you find actions that cause an increase in VM heap size by taking the ‘memorylogic’ gem and adding additional information. It helps you determine which part of your application is the biggest memory hog. In the log the plugin shows you the instantiation breakdown, so you can see places where there might be too many objects called. The oink plugin also shows server metrics such as memory threshold, and presents the worst requests. Then it aggregates them all so you can see which index actions are increasing memory the most. This way, you can determine which methods are causing memory bloat and understand where you need to optimize.

Additional Resources

RailsLab on iTunes
Don’t forget to subscribe to the RailsLab podcast on iTunes where you’ll find the Scaling Rails series as well as our other RailsLab episodes. Download one, or the whole series and play them on your iPhone or computer.

leigh@newrelic.com'

Marketing Manager, Content View posts by .

Interested in writing for New Relic Blog? Send us a pitch!