Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Production R14 (Memory quota exceeded) on web dyno: ideas to fix

Aperta
  • Qualcosa non va?
#7,218 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
rails, ruby
Ambito
backend, infrastructure, performance

Direzione di ricerca

Start with app/controllers/health_controller.rb and lib/tasks/post_gc_stat_to_discord.rake, then inspect config/puma.rb and the Procfile. Run the listed Heroku configuration and process commands, and check Scheduler and Scout APM around the R14 windows. Done should mean the cause is supported by production evidence and one scoped mitigation is implemented and verified without introducing another memory spike.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

Production (casa-production, web.1) is logging repeated R14 (Memory quota exceeded) errors. On 2026-09-30 from about 05:42 to 05:56 UTC, it logged one every ~20s. The errors repeat steadily for 15+ minutes, so memory went up and stayed up. That usually means one big spike that Ruby didn't give back to the OS, not a steady load.

Ideas, most likely first

1. /health/old_objects may be causing the spikes

app/controllers/health_controller.rb (old_objects) walks every object in the web process three times. For each one it calls ObjectSpace.dump(obj), which builds a JSON string, just to check "old":true. That's hundreds of thousands of throwaway strings per request, inside the web dyno. Ruby's allocator rarely returns that memory to the OS, so one call can leave the dyno above quota.

If Heroku Scheduler runs rake post_gc_stat_to_discord (lib/tasks/post_gc_stat_to_discord.rake), the tool meant to diagnose memory would be adding to it.

  • Check whether post_gc_stat_to_discord is scheduled, and whether R14 bursts start shortly after it runs
  • Fix: remove the endpoint and task, or rewrite it to use only cheap stats (GC.stat, ObjectSpace.count_objects). Scout APM already covers most of this.
2. Tune the memory allocator

Nothing sets MALLOC_ARENA_MAX or jemalloc. Rails apps on glibc malloc with several threads fragment badly.

  • heroku config:set MALLOC_ARENA_MAX=2: one env var, often cuts memory by 20–40%
  • Or add a jemalloc buildpack. That's usually better, but it's more setup.
3. Check the process and thread count

config/puma.rb sets 3 threads and never sets workers, so the process count depends on WEB_CONCURRENCY in prod. 2+ processes on a 512MB dyno could cause this alone.

  • Check WEB_CONCURRENCY / RAILS_MAX_THREADS / dyno size
  • Consider single mode (or 1 worker), or a 1GB dyno if more capacity is needed
4. Look for heavy requests

These build everything in memory within the web request:

  • Case contact / mileage / followup CSV exports and caxlsx spreadsheets

  • Sablon court reports (.docx)

  • pdf-forms fund request PDFs

  • Use Scout APM's memory-allocation view to find the endpoints with the most allocations around the R14 windows

  • Fixes: stream CSVs, find_each, move generation into a background job

Related: delayed_job is the ActiveJob adapter, but the Procfile has no worker process, so check how jobs actually get run.

5. YJIT

config.load_defaults 8.1 turns YJIT on, which adds tens of MB. It's worth keeping for speed, but as an experiment try RUBY_YJIT_ENABLE=0 or a lower --yjit-mem-size if we're at the limit.

6. Temporary relief

Restart when memory runs high (e.g. puma_worker_killer, or a scheduled restart). This hides the leak rather than fixing it, so only use it while we find the cause.

Commands to confirm

heroku config -a casa-production | grep -iE 'WEB_CONCURRENCY|MAX_THREADS|MALLOC|YJIT'
heroku ps -a casa-production
heroku addons:open scheduler -a casa-production

Suggested first steps: #1 and #2. Both are small, low-risk changes and the most likely fixes.

🤖 Generated with Claude Code

Lingua principale
Ruby
Stelle
382
Fork
546
Merge medio
3g 5h
PR unite (30g)
9

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rubyforgood/casa

Tutte le issue di rubyforgood/casa

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.