Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#7,218 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
活発
技術スタック
rails, ruby
領域
backend, infrastructure, performance

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
Ruby
スター
382
フォーク
546
平均マージ
3日 5時間
マージ済み PR（30日）
9

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

rubyforgood/casa のほかの issue

rubyforgood/casa の issue をすべて見る

似ている issue

Ruby の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。