Ruby Execution Models and Threading

5 posts · Oct 2019 – Apr 2023

What this trail covers

Shopify has evolved its Ruby execution models and threading strategies to optimize garbage collection performance within its monolithic application. Initial efforts focused on reducing the latency impact of the Ruby garbage collector (GC) by analyzing and tuning its behavior. Key developments include addressing major GC triggers like `:oldmalloc` and `:nofree` by adjusting GC limits and pre-allocating heap slots. The introduction of Ruby 3.2's variable width allocation necessitated a finely-grai

All Shopify trails

Apr 2023Adventures in Garbage Collection: Improving GC Performance in our Massive Monolith - ShopifyThis post details specific tuning of Ruby's garbage collector to reduce latency in Shopify's monolith. It addresses major GC triggers like `:oldmalloc` by setting a high limit and `:nofree` by implementing finely-grained preallocation of heap slots using a custom hack and later a Ruby feature. The work involved extensive logging, metric analysis, hypothesis formation, and experimentation, leading to significant reductions in GC time and improved tail latency.
Dec 2022Optimizing Ruby’s Memory Layout: Variable Width Allocation - ShopifyThis post details the introduction of Variable Width Allocation (VWA) in Ruby 3.2, a feature authored by Shopify engineers and others. VWA optimizes Ruby's memory layout by introducing dynamic sizing for objects, moving away from the fixed 40-byte RVALUE slot. This includes the introduction of 'size pools' with slot sizes as powers of two multiples of RVALUE size (40, 80, 160, 320, 640 bytes) to improve memory utilization and reduce fragmentation. The heap page size was increased from 16 KB to 64 KB to accommodate larger slot sizes and reduce page allocation overhead. Compaction was modified to move objects between optimal size pools. Four types (classes, arrays, strings, and objects) are now covered by VWA, with classes being the first fixed-size type implemented. Benchmark results show performance improvements, and the work enables cutting-edge GC research.
May 2022To Thread or Not to Thread: An In-Depth Look at Ruby’s Execution Models - ShopifyThis post delves into the mechanics and reasoning behind the popularity of threaded servers (like Puma and Sidekiq) in Ruby applications. It explains the memory usage model of web applications, differentiating between static and processing memory, and introduces the concept of Copy-on-Write (CoW) to illustrate how forked processes can share memory. The post critically examines memory metrics like RSS, PSS, and `smaps_rollup` to accurately measure memory usage and improve CoW efficiency. It provides practical advice on configuring servers for full application loading and leveraging `eager_load_namespaces` to improve CoW. Finally, it argues for the continued use of process-based servers (like Unicorn and Resque) by highlighting their advantages in clean timeout mechanisms and resiliency, which are difficult to achieve with threads.
Aug 2021Diggin’ and Fetchin’ with TruffleRuby - ShopifyThis post details the investigation into a performance issue in TruffleRuby related to nested hash access. The author identified a clever but inefficient Ruby pattern using chained `Hash#fetch` and proposed refactoring it using `Hash#dig`. Further investigation revealed that `Hash#dig` and the proposed `dig_fetch` method (implemented recursively) suffered from performance degradation at deeper nesting levels compared to `Hash#fetch`. This led to an exploration of adding a new method to Ruby hashes in TruffleRuby, culminating in a prototype implementation of `dig_fetch` that aims to combine the flexibility of `fetch` with the traversal of `dig`. Benchmarking revealed a performance cliff with recursive implementations, suggesting an iterative approach might be more performant for deep nesting.
Nov 2019Sam Saffron AMA: Performance and Monitoring with Ruby - ShopifyThis post contributes to the thread by highlighting the critical need for improved memory profiling tools in MRI, comparing them unfavorably to Java and .NET. It emphasizes that the primary performance bottleneck for Discourse is memory, not CPU, and advocates for the Ruby community to focus on solving real-world production pain points, especially memory-related issues. The post also touches upon the importance of clear goals and breaking down complex performance problems into manageable steps, using memory leak detection as an example.
Advertisement
Oct 2019How to Write Fast Code in Ruby on Rails - ShopifyThis post details strategies for writing fast code in Ruby on Rails, covering Active Record performance (lazy evaluation, selecting less, query cache, indexing), Rails performance (caching, throttling with rack-attack, background jobs with Active Job, dependency management), and Ruby performance (sparing use of metaprogramming, understanding O(n) vs O(1) complexity, minimizing object allocations with `uniq!` vs `uniq`). It also mentions Large Hadron Migrator (LHM) for database migrations.