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
If you are using the popular Unicorn web server, memory issues may be even more severe, as Unicorn forks. During forking, it's copying the whole memory footprint of the parent (Copy on Write or CoW). Therefore, you may use the " Unicorn Worker Killer " gem that will monitor your server and gracefully will restart specific worker when memory reaches a new high or specific number of requests were served. Since the gem supports randomization, it assures in a very high probability that the server will continue server.
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
You can take a look at a detailed discussion at collective idea's post.
The Bottom Line
Dynamic languages have their downs, yet w/ the right design you can keep them up and running.
Keep Performing! -Moshe Kaplan
Topics:
server,
memory,
issues,
performance,
web,
ruby,
garbage collection
Published at DZone with permission of Moshe Kaplan, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments