Fix for major memory leak / slowdown proportionate to number of serviced requests. #466

wants to merge 4 commits into


None yet
3 participants

MrJoy commented Sep 9, 2011

Prevent exponential increase in listeners. Works in Rails 3.0, and hopefully works in 3.1 too (I have not tested this, but the latest commit is in response to my last effort not working in Rails 3.1, and superficially should be robust).


j-manu commented Sep 19, 2011

Has this been tested ? Will it be merged?

MrJoy commented Sep 19, 2011

I've tested it against Rails 3.0 and it works well there. I've not tested against 3.1 as our app requires some significant work to bring up under 3.1. At a minimum, I would expect it to not be harmful in 3.1 but it would be nice if someone could pick this up and test it.

MrJoy closed this Sep 19, 2011

MrJoy reopened this Sep 19, 2011

MrJoy commented Sep 19, 2011

Whoops, didn't mean to close the request. >.<

MrJoy commented Sep 19, 2011

Did a quick test in 3.1, and there still appears to be memory leaks and significant per-request slowdowns even with this fix. That said, in some informal testing (hitting a static page where the controller does a GC.start, then looking at the process RSS, wash-rinse-repeat x100) this reduces average post-request RSS by 5.1MiB.

Behavior appears to be sane and correct from my superficial testing.

MrJoy commented Sep 19, 2011

Doing the same sort of test against our Rails 3.0 app and I see similar behavior -- this makes things better, and makes things degrade better (memory leaks only, not memory + time), but they still degrade.

So I suggest landing this but keep plugging away to find what's going on.


gregbell commented Sep 21, 2011

I've spent some time today looking into the memory issues, but haven't found the exact issue yet.

When I use the tooling you supplied on #170 I get:

module ActiveAdmin
  class Reloader
    def attach!
      STDERR.puts ">>>>>>>>>>>>>>>>>>>   ATTACH!"
      reloader_class.to_prepare do
        STDERR.puts ">>>>>>>>>>>>>>>>>>>   RELOAD!"

I get the output:

=> Booting WEBrick
=> Rails 3.0.10 application starting in development on
=> Call with -d to detach
=> Ctrl-C to shutdown server
>>>>>>>>>>>>>>>>>>>   ATTACH!
>>>>>>>>>>>>>>>>>>>   RELOAD!
[2011-09-20 17:09:23] INFO  WEBrick 1.3.1
[2011-09-20 17:09:23] INFO  ruby 1.8.7 (2009-06-12) [i686-darwin11.0.0]
[2011-09-20 17:09:23] INFO  WEBrick::HTTPServer#start: pid=57789 port=3000
>>>>>>>>>>>>>>>>>>>   RELOAD!

Started GET "/admin/categories" for at Tue Sep 20 17:09:27 -0700 2011
  Processing by Admin::CategoriesController#index as HTML
  SQL (0.6ms)   SELECT name
 FROM sqlite_master
 WHERE type = 'table' AND NOT name = 'sqlite_sequence'

  AdminUser Load (0.2ms)  SELECT "admin_users".* FROM "admin_users" WHERE "admin_users"."id" = 1 LIMIT 1
  Category Load (0.6ms)  SELECT "categories".* FROM "categories" ORDER BY "categories".id desc LIMIT 30 OFFSET 0
  SQL (0.1ms)  SELECT COUNT(*) FROM "categories"
  CACHE (0.0ms)  SELECT COUNT(*) FROM "categories"
Rendered /Users/gregbell/code/active_admin/app/views/active_admin/resource/index.html.arb (119.6ms)
Completed 200 OK in 158ms (Views: 126.5ms | ActiveRecord: 1.4ms)
>>>>>>>>>>>>>>>>>>>   RELOAD!

Which has 1 attach and then a reload on each page. Isn't this how the reloader should work? (This is before your patch)

Somewhere in Active Admin we're holding on to references of Namespaces that aren't being cleared out in Application#unload!

Are you getting different mileage?

MrJoy commented Sep 21, 2011

Definitely getting different mileage -- perhaps having to do with being on Ruby 1.9.2-p180?


gregbell commented May 16, 2012

Closing for now since memory issues seem to have been dealt with. Please open a new pull request if there are additional fixes that you would like to see.

gregbell closed this May 16, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment