Ruby VM measurements

Available on: CRuby 2.0+

The number of Ruby objects allocated in your processes. In the UI, this measurement is normalized by the number of requests, so that you can get a sense of how many objects are allocated per request.

This is an important number to watch, since the frequency of object allocations is one of the biggest drivers for how often Ruby's garbage collector must run.

On CRuby, this value is derived from GC.stat[:total_allocated_object].

Available on: CRuby 1.9.2+, Rubinius 2.x (see note below about JRuby support)

The amount of time spent in garbage collection (both mark and sweep phases) in your Ruby processes.

The Ruby agent actually measures this value in two different ways: garbage collection time that is incurred in the middle of request processing, and total garbage collection time. Garbage collection time that happens in the middle of request processing is presented as a band on the main overview graph, and in the breakdown charts for individual transactions. Total GC time as a percentage of wall-clock time is shown on the Ruby VMs tab.

This measurement is derived from GC::Profiler.total_time.

Note: You must enable GC::Profiler in order to get this measurement. For more information, see GC instrumentation.

JRuby note: Due to what appears to be a bug in either JRuby or certain versions of the JVM, GC timings may be off by a factor of 1000 on JRuby. For this reason, we don't currently recommend enabling GC::Profiler on JRuby.

Available on: CRuby 1.9.2+, JRuby 1.7+, Rubinius 2.x

How often does the garbage collector need to stop your Ruby process in order to run? On CRuby 2.1+, this will be segmented into major and minor GC runs. This number is presented in the UI as the number of requests processed per GC run.

Depending on the version of Ruby in use, this value may be derived from GC.count, or from GC.stat[:minor_gc_count] and GC.stat[:major_gc_count].

Available on: CRuby 1.9.2+

The Ruby interpreter stores objects on a heap, with each object occupying a single heap slot. As slots within the heap fill up with objects, the heap will be expanded by the Ruby VM as necessary.

The Ruby agent measures both the number of live objects in the heap, and the number of unoccupied heap slots on a periodic basis.

Generally speaking, the more objects there are on the heap, the longer each GC run will take (since potentially every object on the heap must be examined). More objects on the heap also correlates to higher memory usage for your application.

This value is derived from GC.stat[:heap_live_slot] or GC.stat[:heap_live_num], and GC.stat[:heap_free_slot] or GC.stat[:heap_free_num].

Available on: Any Ruby version

This measurement shows the memory usage (resident set size) of your Ruby processes, presented as the average size per instance (process). Keeping memory usage in check is an important consideration when tuning your Ruby VM settings. If it grows too large, you can cause the host machine to start paging to disk, or bump up against software-enforced memory limits.

On Linux hosts, this is derived from the VmRSS field of /proc/PID/status.

Available on: CRuby 2.1+

Every time a method is invoked on an object, Ruby must locate the implementation of that method by searching up the ancestor chain of the object. Because these searches are expensive, the Ruby VM will cache the results of these searches.

In older versions of CRuby (prior to 2.0), there was a single, global method cache, and there were a variety of operations that could cause the entire cache to be invalidated.

In CRuby 2.1 or higher, the global cache has been broken up into a set of smaller, per-class caches, so that cache-invalidating changes to one class won't throw out cache entries for other unrelated classes.

There are, however, still some operations that will cause all method caches to be invalidated. The Ruby agent will measure how frequently these invalidations happen, and report this measurement normalized against the number of requests, to give you an idea of how many times per request all of the method caches are invalidated.

For more information, see this blog post by Aman Gupta.

This value is derived from RubyVM.stat[:global_method_state].

Available on: CRuby 2.1+

Ruby caches the locations of constants in a way that's similar to the method caching behavior described above. The Ruby agent can also measure the number of times the global constant cache is invalidated, and report this as an average number of invalidations per request.

This value is derived from RubyVM.stat[:global_constant_state].

Available on: CRuby 1.9.2+, JRuby 1.7+, Rubinius 2.x

The Ruby agent can keep track of the number of threads in your Ruby processes. If you're using a multi-threaded web server, this can be used to confirm that your thread pool is actually the size you have configured it to be. It can also highlight if you have a thread leak (where you're spawning threads that never get torn down).