puma-tuning-and-concurrency

Configure Puma worker and thread sizing for Rails 8 production deployments.

21|2|Updated May 24, 2026
One-click install
npx skills add https://github.com/sandeepmvl/rails-skills --skill puma-tuning-and-concurrency
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: puma-tuning-and-concurrency
Source: https://github.com/sandeepmvl/rails-skills/tree/main/skills/27-puma-tuning-and-concurrency
Command: npx skills add https://github.com/sandeepmvl/rails-skills --skill puma-tuning-and-concurrency

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Misconfigured Puma is the most common Rails performance issue after N+1 queries. Default Puma settings are overly conservative, leading to wasted memory, poor concurrency, and missed throughput gains for production Rails applications.

Core Features & Use Cases

  • Workload-aware sizing formulas: Calculates optimal worker count (CPU cores × 1.5 for I/O-bound, ×1 for CPU-bound) and thread count per worker (3-5 default, up to 10 for I/O-heavy workloads) based on your server specs and app type.
  • Memory optimization integration: Guides setup of jemalloc, MALLOC_ARENA_MAX=2, and YJIT for Ruby 3.3+ to cut memory usage by 20-40% and boost throughput by 10-25%.
  • Production-safe configuration: Provides copy-on-write compatible Puma config with preload_app!, fork-safe on_worker_boot hooks for DB/cache reconnection, and PumaWorkerKiller setup to bound memory bloat from leaks.
  • Use Case: A team running a 4-CPU I/O-bound Rails 8 monolith uses this skill to configure 6 Puma workers with 5 threads each, enabling 30 concurrent requests with a ~2.4GB total memory budget, avoiding overprovisioning and underutilization.

Quick Start

Use the puma-tuning-and-concurrency skill to calculate the optimal Puma worker count, thread count, and memory settings for your production Rails 8 deployment on a 4-CPU I/O-bound server.

Frequently Asked Questions about puma-tuning-and-concurrency

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I calculate optimal Puma worker and thread counts for Rails production?

Puma worker count is calculated by multiplying CPU cores by 1.5 for I/O-bound workloads or 1 for CPU-bound workloads. Configure 3-5 threads per worker by default, scaling up to 10 threads for I/O-heavy Rails applications to maximize concurrency.

Why does my Rails application use so much memory with default Puma settings?

Default Puma configurations lack copy-on-write memory optimization and leak mitigation. Integrating jemalloc, setting MALLOC_ARENA_MAX=2, and configuring PumaWorkerKiller bounds memory bloat, cutting Rails production memory usage by 20-40%.

Do I need YJIT and jemalloc to improve Rails Puma throughput?

YJIT and jemalloc are recommended for Ruby 3.3+ Rails deployments to boost Puma throughput by 10-25%. YJIT accelerates Ruby execution while jemalloc optimizes memory allocation, significantly enhancing overall production performance.

What's the best way to configure fork-safe database connections in Puma workers?

Use preload_app! for copy-on-write compatibility and implement fork-safe on_worker_boot hooks in your Puma config. This ensures database and cache connections are properly reconnected after Puma workers fork, preventing connection leaks in Rails production.

Can I use PumaWorkerKiller to bound memory leaks in Rails 8 applications?

PumaWorkerKiller is configured to bound memory bloat from leaks in Rails 8 applications. It automatically restarts Puma workers that exceed defined memory limits, maintaining stable production memory usage without manual intervention.