Skip to content

Instantly share code, notes, and snippets.

@nshoes

nshoes/debug-ruby-memory-leak.md

Last active April 17, 2020 15:36
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save nshoes/5d689a4053f21b18452621338b7f0c06 to your computer and use it in GitHub Desktop.
Save nshoes/5d689a4053f21b18452621338b7f0c06 to your computer and use it in GitHub Desktop.
Download ZIP
Debug Ruby Memory Leak
Raw
debug-ruby-memory-leak.md

Read

https://samsaffron.com/archive/2015/03/31/debugging-memory-leaks-in-ruby

Instrument

ObjectSpace.trace_object_allocations_start
file = File.open("/some/path/#{Time.now.to_f}-heap.dump", 'w')
ObjectSpace.dump_all(output: file)
file.close

Note that this instrumentation code needs to be in the Ruby process that is gobbling memory. In a multi-threaded environment, like Sidekiq, this code needs to be executed in a worker.

Analyze

Install Heapy, then:

heapy read some/path/123.456-heap.dump

Note the generation # that seems unusualy high, then:

heapy read 1587078651.3178177-heap.dump GENERATION_NUMBER

Don't forget to check multiple generations. High object counts arent' a bad thing, and it could just be a normal workload before GC kicks in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment