如何排查并降低Heroku上Rails应用的启动内存占用

Let’s dive into your startup memory issue and break down actionable steps to diagnose and fix it.

Do Your before_filter Variables Impact Startup Memory? #

Short answer: No, not directly. The code in your before_filter runs per request, not during the application startup phase. Rails initializes the app first, then waits for incoming requests—these instance variables (@search, @nbr_of_stores_total, etc.) are created and destroyed within each request cycle, so they don’t contribute to your 430MB startup footprint.

That said, keep an eye out if any of the methods called here (like Store.active.size) are being invoked elsewhere during startup (e.g., in an initializer). If so, that would add to startup memory, but the before_filter itself isn’t the culprit here.

Key Areas to Investigate for Startup Memory Bloat #

Start checking these spots—they’re the most common sources of startup memory overhead:

• Initializers (config/initializers/):
  Many gems and custom code run here during startup. Look for code that preloads large datasets (e.g., Store.all.each { ... }), initializes global objects, or sets up connections (like database pools or external API clients) that stay resident in memory. Even small objects add up if they’re created during startup.

• Middleware:
  Rails loads a default set of middleware, plus any added by gems (e.g., Devise, CarrierWave). Use rails middleware to list all loaded middleware. If you’re not using some (e.g., Rack::Cache if you use a CDN), remove them via config.middleware.delete in config/application.rb to cut down on initialization overhead.

• Gem Initialization Overhead:
  derailed bundle:mem measures gem code size, but many gems do extra work during startup (e.g., CarrierWave-AWS initializing an S3 client, or a gem preloading configuration). Check gem docs for ways to delay initialization until first use (if possible) or disable unused features.

• Eager Loading:
  Production environments default to config.eager_load = true, which loads all models, controllers, and lib files during startup. If you have large lib files or models that are only used in rare requests, consider moving them to a directory that’s not eager loaded, or lazy-load them with require_dependency when needed.

• Global Objects/Constants:
  Any global variables, class variables, or singleton objects created during startup (e.g., in models or initializers) stay in memory indefinitely. Audit your code for things like $global_data = SomeLargeDataset.load or class SomeClass; @@cache = {}; end that get populated at startup.

Tools to Pinpoint High-Memory Startup Operations #

These tools will help you zero in on exactly what’s eating up memory during startup:

• derailed_benchmarks:
  Beyond bundle:mem, run bundle exec derailed exec perf:mem—this tracks memory usage as your app starts up, outputting a step-by-step breakdown of where memory grows. You’ll see exactly which initialization step (e.g., loading a model, initializing a gem) causes spikes.

• memory_profiler:
  Wrap your Rails startup in a memory profiler to get a detailed report of object allocations. Create a simple script like this:

  require 'memory_profiler'
  require_relative 'config/environment'
  
  report = MemoryProfiler.report do
    Rails.application.initialize!
  end
  
  report.pretty_print(to_file: 'memory_report.txt')
  

  Run it with ruby memory_profile.rb, then check the report for objects with the highest allocation counts or total size.

• ruby-prof:
  Use its memory profiling mode to find methods that allocate the most memory during startup. Run:

  ruby-prof --mode memory -p rails server
  

  The generated report will show you which methods are responsible for the biggest memory hits.

• Rails Debug Logs:
  Temporarily set config.log_level = :debug in production (or use development mode, though production is more accurate) and check the startup logs. Look for slow or resource-heavy initialization steps (e.g., "Loaded 1000 Store records" in an initializer).

How to Measure Memory Savings Locally #

You don’t need to deploy to Heroku to validate your fixes—use these local methods:

• ps Command:
  Start your Rails server, then run ps aux | grep rails and look at the RES (resident memory) column. Note the value, make your code changes, restart the server, and compare the new RES value.

• memory_profiler Reports:
  Generate reports before and after your changes, then compare total allocated bytes, object counts, and top allocators. A drop in total allocated memory means your changes are working.

• derailed exec perf:mem:
  Run this command before and after fixes—its final "Total allocated" and "Total retained" values will show you exactly how much memory you’ve saved.

• rack-mini-profiler:
  Install this gem locally, and its memory panel will show you the current process memory usage after startup. It’s a quick, visual way to verify changes.

Quick Bonus Tip for Runtime Memory (Even Though It’s Not Your Main Target) #

While your before_filter doesn’t affect startup memory, you can optimize those database queries to reduce runtime memory growth. Cache results with Rails.cache.fetch:

@nbr_of_stores_total = Rails.cache.fetch('stores_active_count', expires_in: 1.hour) do
  Store.active.size
end

This avoids querying the database on every request and cuts down on runtime object allocations.

内容的提问来源于stack exchange，提问作者Christoffer