Ruby Is Dead! - You Need to Take Care of Its Memory Issues
In this post, we take a look at how to address common memory usage issues that can occur in Ruby. Read on to find out more!
Join the DZone community and get the full member experience.
Join For FreeOne of the common problems with Ruby is its memory usage, just like JVM-based languages (yes Java, I'm talking about you). Actually, Ruby just like Java is based on garbage collector. This GC, if not used correctly, can cause "stop the world scenarios" (as we can see in the attached diagram). In these cases, the GC actually stops responding while consuming the server's whole CPU and in some cases even causes a server reboot.
Unicorn and Ruby memory leak causes server downtime.
What Can Be Done?
Reboot Your Ruby Periodically
Installing the killer:
gem 'unicorn-worker-killer'
Add to config.ru above "require ::File.expand_path('../config/environment', __FILE__)"
# Unicorn self-process killer
require 'unicorn/worker_killer'
And decide your worker graceful reboot method:
# Max requests per worker
use Unicorn::WorkerKiller::MaxRequests, 3072, 4096
# Max memory size (RSS) per worker
use Unicorn::WorkerKiller::Oom, (192*(1024**2)), (256*(1024**2))
Tune Your Memory
If you are using Ruby 2.X, you can exploit the CoW by better configuring Unicorn.
config/unicorn.rb (and a detailed explanation on setting at sirupsen
- - worker_processes: 1x your cores
- - timeout: worker request timeout, should be 15 to 30 sec max
- - preload_app: enables CoW, but requires managing connect/disconnect on fork
Take Care of GC Configuration
The Bottom Line
Dynamic languages have their downs, yet w/ the right design you can keep them up and running.
Keep Performing! -Moshe Kaplan
Published at DZone with permission of Moshe Kaplan, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments