# Debugging memory leaks in Ruby

DevFeed: [Debugging memory leaks in Ruby](<https://devfeed.tech/articles/debugging-memory-leaks-in-ruby-41338.md>)

Original publisher: [Read original article](<https://samsaffron.com/archive/2015/03/31/debugging-memory-leaks-in-ruby>)

Author: Sam Saffron

Published: 2015-03-31T06:44:39Z

Content type: tutorial

Language: en

Sources: [Sam Saffron](<https://devfeed.tech/sources/sam-saffron.md>)

Topics: [Memory Leaks](<https://devfeed.tech/topics/memory-leaks.md>), [Ruby](<https://devfeed.tech/topics/ruby.md>), [debug](<https://devfeed.tech/topics/debug.md>), [Rails](<https://devfeed.tech/topics/rails.md>), [Grafana](<https://devfeed.tech/topics/grafana.md>), [Docker](<https://devfeed.tech/topics/docker.md>), [Processes](<https://devfeed.tech/topics/processes.md>), [Monitoring](<https://devfeed.tech/topics/monitoring.md>)

Tags: [debugging](<https://devfeed.tech/tags/debugging.md>), [docker](<https://devfeed.tech/tags/docker.md>), [grafana](<https://devfeed.tech/tags/grafana.md>), [memory-leaks](<https://devfeed.tech/tags/memory-leaks.md>), [metrics](<https://devfeed.tech/tags/metrics.md>), [process](<https://devfeed.tech/tags/process.md>), [rails](<https://devfeed.tech/tags/rails.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [sidekiq](<https://devfeed.tech/tags/sidekiq.md>)

## AI overview

A practical guide to diagnosing memory leaks in Ruby and Rails applications. It recommends graphing memory over time, tracking RSS for key processes such as Unicorn and Sidekiq, and examining memory-growth trends across Docker containers.

## Source excerpt

At some point in the life of every Rails developer you are bound to hit a memory leak. It may be a tiny amount of constant memory growth, or a spurt of growth that hits you on the job queue when certain jobs run. Sadly, most Ruby devs out there simply employ monit , inspeqtor or unicorn worker killers. This allows you to move along and do more important work, tidily sweeping the problem snugly under the carpet. Unfortunately, this approach leads to quite a few bad side effects. Besides performance pains, instability and larger memory requirements it also leaves the community with a general lack of confidence in Ruby. Monitoring and restarting processes is a very important tool for your arsenal, but at best it is a stopgap and safeguard. It is not a solution. We have some amazing tools out there for attacking and resolving memory leaks, especially the easy ones - managed memory leaks. Are we leaking ? The first and most important step for dealing with memory problems is graphing memory over time. At Discourse we use a combo of Graphite , statsd and Grafana to graph application metrics. A while back I packaged up a Docker image for this work which is pretty close to what we are running today. If rolling your own is not your thing you could look at New Relic, Datadog or any other cloud based metric provider. The key metric you first need to track is RSS for your key Ruby processes. At Discourse we look at max RSS for Unicorn our web server and Sidekiq our job queue. Discourse is deployed on multiple machines in multiple Docker containers. We use a custom built Docker container to watch all the other Docker containers. This container is launched with access to the Docker socket so it can interrogate Docker about Docker. It uses docker exec to get all sorts of information about the processes running inside the container. Note: Discourse uses the unicorn master process to launch multiple workers and job queues, it is impossible to achieve the same setup (which shares memo