Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory Leak Issue with derailed and Rails Configuration #257

Open
gatopanx opened this issue Oct 26, 2024 · 3 comments
Open

Memory Leak Issue with derailed and Rails Configuration #257

gatopanx opened this issue Oct 26, 2024 · 3 comments

Comments

@gatopanx
Copy link

First and foremost, thank you for this outstanding tool! It has been incredibly helpful in identifying memory issues, and I truly appreciate the work that’s gone into it.

While debugging some memory leaks, I happened to find a discrepancy that I wanted to bring to your attention. When I ran:

bundle exec derailed bundle:mem

I noticed that a nested dependency was significantly increasing memory usage on boot, even with the default Rails configuration:

   1 TOP: 176.2227 MiB
   2   rails/all: 58.1875 MiB
   3     action_mailbox/engine: 31.2695 MiB
   4       action_mailbox: 31.2539 MiB
   5         action_mailbox/mail_ext: 31.25 MiB
   6           action_mailbox/mail_ext/address_equality.rb: 28.8984 MiB
   7             mail/elements/address: 28.8945 MiB
   8               mail/parsers/address_lists_parser: 28.8672 MiB
   9           mail: 2.3516 MiB
  10             mail/field: 0.5234 MiB
  11             mail/message: 0.4102 MiB

To address this, I adjusted config/application.rb to load only the required components:

require_relative 'boot'

require 'rails'
require 'active_model/railtie'
require 'active_job/railtie'
require 'active_record/railtie'
require 'active_storage/engine'
require 'action_controller/railtie'
require 'action_mailer/railtie'
# require 'action_mailbox/engine'
require 'action_text/engine'
require 'action_view/railtie'
require 'action_cable/engine'
require 'sprockets/railtie'
require 'rails/test_unit/railtie'

# ...other configurations

However, upon re-running bundle exec derailed bundle:mem, the memory consumption results remained unchanged. After investigating further, I found that derailed appears to load the full Rails stack regardless of the configuration in config/application.rb. The relevant code is here: https://github.com/zombocom/derailed_benchmarks/blob/main/bin/derailed#L90.

This behavior may not align with users’ expectations, especially when debugging memory issues, as it could lead to a mismatch between actual application memory usage and what derailed reports. I understand that the documentation does mention that certain components (e.g., ActiveRecord) can be skipped, but the current behavior could be misleading when attempting more granular memory optimization.

Would it be possible to consider an enhancement that allows derailed to respect the customized Rails boot process, or to clarify this behavior in the documentation?

Thank you again for all your efforts on this project! Happy to assist further if needed.

Best,
Ivan

@jkotchoff
Copy link

I was also looking at reducing my memory footprint by eliminating action_mailbox however I note that If you roll config/application.rb back to:
require "rails/all"

and then run:
RAILS_ENV=production rails server

and then run:
bundle exec derailed exec perf:mem

then action_mailbox will not show in your memory footprint anymore without any need to selectively require rails gems.

I suspect rails is lazy loading it. It is a bit confusing that the static benchmarking identifies gems like this in the default output of derailed however the documentation does say "Booting your app will always be more accurate".

@pcai
Copy link
Contributor

pcai commented Jan 1, 2025

derailed bundle:mem has no way to know that you have included a gem in your bundle but not loaded it, unless it actually runs your app - I agree this is confusing and sometimes unintuitive, but this is well-documented in the readme (see screencap below). I would welcome a PR to further clarify things or call out some of the specific cases you ran into.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants