How the Ruby Global VM Lock impacts app performance
summary
Ruby 3.2 adds a GVL instrumentation API and the gvl-tracing gem produces Perfetto timelines that show threads switching on a 100 ms quantum, revealing that adding a CPU-bound background thread turns a network test from ~17 requests/sec to ~2 requests/sec. Ractors give true parallelism but MN scheduling defaults to eight native threads so Ruby 3.3 maps many Ruby threads onto few OS threads. The experiments are reproducible, visual, and used to recommend separating latency‑sensitive work and starting Puma around 4 workers 5 threads.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 1:44What is the Ruby Global VM Lock
- 3:52Ruby threads to OS threads
- 5:16GVL vs GIL naming
- 6:20GVL allows concurrency not parallelism
- 7:23Why Ruby needs concurrency APIs
- 9:54Ruby implementations without GVL
- 10:15GVL tracing tools
- 11:16Reading GVL timelines
- 13:03Threads vs latency impact
- 14:49Ruby threads as noisy neighbors
- 16:14Network calls and GVL fairness
- 18:40GVL is not always fair
- 19:44Ractors and M:N scheduling
- 22:14Ruby threads and OS mapping
- 23:40Ruby 3.3 M:N scheduler
- 24:42Key insights from timelines
- 25:25Monitoring GVL with tools
- 26:07Practical recommendations
- 28:15Future of Ruby and GVL
related talks
35mIn defence of GVL
38m"Parallel and Thread-Safe Ruby at High-Speed with TruffleRuby"
43mParallel and Thread-Safe Ruby at High-Speed with TruffleRuby
28mConcurrency for Rubyists
23mParallel Processing With Ruby
38mScaling Ruby with Actors, or How I Learned to Stop Worrying and Love Threads
33mConcurrency for !Dummies (Who Don't Get It (...Yet))
40mRUBY 3.0 - SINGLE PROCESS, MULIPLE POSSIBILITIES