Parser causes memory leak problem

[mquan]

I have a rails app that dynamically compiles less to css based on user inputs and have noticed significant memory leakage that crashes the app after running for about 30 minutes. Using the oink gem, I was able to pinpoint the cause, which is the parse method that creates the Less::Tree. The memory leak occurs even before calling to_css

It seems like something isn't deallocated properly and I just wonder if there's any hook for me to manually destroy everything created by the parse method.

Thanks

[cowboyd]

Do you have code reloading turned on?

[mquan]

I don't know what that feature is, so I assume no. I just use it the way the doc instructs:

parser = Less::Parser.new
tree = parser.parse("/* my less code */") #this here causes leakage
css = tree.to_css

[cowboyd]

There are a couple things that it could be

Remember that you have a completely separate virtual machine living inside your ruby process. By default, the V8 interpreter will not even start garbage collecting javascript objects until it has allocated something like 256MB of memory. This can be magnified if those js objects reference ruby objects.

Do you see your usage grow or does it plateau after a certain point?

On Feb 16, 2012, at 1:44 PM, Quan Nguyen wrote:

I don't know what that feature is, so I assume no. I just use it the way the doc instructs:

parser = Less::Parser.new
tree = parser.parse("/* my less code */") #this here causes leakage
css = tree.to_css

---

Reply to this email directly or view it on GitHub:
#20 (comment)

[mquan]

Without the parse method, the oink log reach constant memory usage very quickly. When it's used, the memory usage keeps rising at very predictable rate. The leakage is about 300k per call on fairly large LESS code.

[cowboyd]

On Feb 16, 2012, at 9:02 PM, Quan Nguyen wrote:

Without the parse method, the oink log reach constant memory usage very quickly. When it's used, the memory usage keeps rising at very predictable rate. The leakage is about 300k per call on fairly large LESS code.

What is the highest bound you've seen it reach?

[mquan]

I deployed my app on a heroku dyno, which has 522Mb. The app has about 250Mb when started and memory is maxed out very quickly. I have to restart the app every 30mins or so.

[mbuckbee]

Just curious if there is an update or any further suggestions to this, I'm observing the same behavior that @mquan reported with respect to memory growth.

[mquan]

@mbuckbee I ditched this and just compile less client side, not sure if this fits your problem

[mbuckbee]

@mquan it is an approach I'm considering. Also, I assume that this was for Lavish (which I added as item number 212 over here: http://www.bootstraphero.com/the-big-badass-list-of-twitter-bootstrap-resources)

[nodrog]

I get this memory leak also, and there seems to be no limit to the amount it gobbles up, i have 16GB and took it all in about 4 hours of working on the less files in my rails app.

After restarting rails it drops the memory its using fine, and all is nice and fast again.

If i can give anyone any useful information please let me know what would help.

I am sure a bunch of people are experiencing this and not realising what it is.

Many thanks

[cowboyd]

You have a couple of options 1) make sure you are using the latest version of therubyracer (currently 0.11.4) 2) set V8 resource constraints before using parsing your less files

[nodrog]

thanks cowboyd

I have updated to the latest rubyracer and added the following as a initialiser in rails

constraints = V8::C::ResourceConstraints.new
constraints.set_max_young_space_size 64 * 1024 * 1024 # 64M
constraints.set_max_old_space_size 64 * 1024 * 1024 # 64M
constraints.set_max_executable_size 16 * 1024 * 1024 # 16M
V8::C::SetResourceConstraints(constraints)

the issue is still there, if i update a less file and refresh the browser (development env) then i get a bump in memory on the rails process of about 90mb per refresh.

As i am updating css in less and refreshing often this is a major issue very quickly.

Any help much appreciated.