Huge memory leaks & CPU usage after editing pages.

[jemgold]

Ruby 2.0.0-p195
Rails 3.2.13
ActiveAdmin hooked to this GitHub repo rather than a gem version to fix this issue

Brand new ActiveAdmin install; after changing any tiny detail of any resource (e.g. add a column to an index page) I get insane CPU usage and memory use. I have to kill the process and restart my server.

Any ideas?

[seanlinsley]

I assume that this isn't related to #2278? That is, you're not running in production mode and/or you don't have a huge number of records in your DB.

[jemgold]

Hmm - I'm actually working with an obfuscated dump of my production database but it's only ~1500 rows - reckon that's the culprit? I'm in development mode.

[jemgold]

Update: no, that doesn't look like it's the culprit - I dumped my database and started again; I'm still getting ~100% CPU usage & memory leaks in development mode with ~10 rows on one table when I try changing anything.

[brandoncordell]

I'm seeing the same issues in development (with hardly anything in my database) after just navigating around the admin area (not even editing my records).

Mac Mini: 2.5ghz dual core i5, 4gb of ram
OS X 10.8.4 (everything up to date)
rbenv 0.4.0
ruby 2.0.0-p247
rails 3.2.14

[jtomaszewski]

I'm experiencing this too, in any environment. Disabling better_errors gem fixes the bug.

With better_errors:
Every time I trigger an exception in activeadmin (wrong method name or something), rails server loads a lot of memory and then timeouts the request.

I think it tries to render the exception and then:

1. goes into infinite loop
2. tries to render the local variables, which results in loading all the DB rows -> crash.

This really slows the development time :/

Does anyone has any idea how to wrap the whole activeadmin action with begin; ...; rescue e; puts e; end ?
Or how to disable better_errors only when in activeadmin dashboard?

Note: I think it's active_admin's fault, not better_errors's - It's the only occasion I have so huge memory leak/timeout when using better_errors.

[jemgold]

Thanks @jtomaszewski — that fixes it for me (but obviously not a great solution to have to disable better_errors every time I want to work on my admin panel.

[shekibobo]

I've been seeing this a lot as well. The problem is exactly as @jtomaszewski described. I haven't tried messing with disabling better_errors while working, though.

[seanlinsley]

I'm thinking this is actually Arbre's fault. The slowdown only seems to happen in Arbre's method_missing.

To clarify: what happens for me is the Ruby process pegs the processor for some period of time, then it uploads 30-70 MB of data to Firefox, and then Firefox itself hangs for about 30 seconds as it handles all that data in the DOM.

[shekibobo]

@daxter any thoughts on how to mitigate this problem?

[seanlinsley]

At this point I'm still not sure, though I'm trying to tackle this and #2542 at the same time, by figuring out how Arbre works.

[baxang]

I'm having the same issue as @jtomaszewski described and glad that it has already reported :)

[MrMoins]

+1

[seanlinsley]

Okay, after trying out a number of dependency version combinations I figured out that the problem emerges when moving from Ruby 1.9 to Ruby 2.

This is Ruby 1.9:

And this is Ruby 2:

It looks to me like this is the difference between calling to_s and inspect on Arbre objects.

[seanlinsley]

Ah, looks like Ruby 2.0 changed the behavior of inspect

1.9.3 :001 > Arbre::Context.new.to_s
 => "" 
1.9.3 :002 > Arbre::Context.new.inspect
 => "" 
# -------
2.0.0 :001 > Arbre::Context.new.to_s
 => "" 
2.0.0 :002 > Arbre::Context.new.inspect
 => "#<Arbre::Context:0x007ff4ba121a40 @_assigns={}, @_helpers=nil, @_current_arbre_element_buffer=[#<Arbre::Context:0x007ff4ba121a40 ...>], @arbre_context=#<Arbre::Context:0x007ff4ba121a40 ...>, @children=[]>"

[seanlinsley]

I just created a PR for Arbre that solves this problem ⏫

[baxang]

@seanlinsley Thanks for the hard work! I'm looking forward to the PR merged.

[seanlinsley]

Okay, my Arbre PR has been merged so you can now use the latest code from GitHub to get around this problem.