/ Performance Zone
Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Ruby Is Dead! - You Need to Take Care of Its Memory Issues

DZone 's Guide to

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!

by
·
Sep. 07, 16 · Performance Zone ·
Free Resource

Comment (0)

Save
Tweet
{{ articles[0].views | formatCount}} Views

One 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.

Image title

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

Like This Article? Read More From DZone

Idle Memory GC Memory Yanking
Visualizing Garbage Collection in Ruby and Python
Introduction to Hazelcast HD Memory

Free DZone Refcard

Introduction to Docker Monitoring
DOWNLOAD
Topics:
server ,memory ,issues ,performance ,web ,ruby ,garbage collection

Comment (0)

Save
Tweet
{{ articles[0].views | formatCount}} Views

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

Performance Partner Resources

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.linkDescription }}

{{ parent.urlSource.name }}
by {{ parent.authors[0].realName || parent.author}}
· {{ parent.articleDate | date:'MMM. dd, yyyy' }} {{ parent.linkDate | date:'MMM. dd, yyyy' }}
· {{ parent.portal.name }} Zone