Ruby on Rails | Screencasts | Download | Documentation | Weblog | Community | Source

Ticket #2589 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

render_component leaks memory

Reported by: scott@sigkill.org Assigned to: htonl
Priority: high Milestone:
Component: ActionPack Version: 0.14.1
Severity: normal Keywords: memory leak components
Cc:

Description

render_component in 0.14.1 leaks memory. When running under FastCGI, an app that uses render_component can quickly grow to use over 100 MB per dispatcher. Typo uses render_component for sidebars, and this has caused a number of complaints recently. A number of TextDrive users have been having serious problems with this. I'm able to duplicate the leak with a minimal test program, see http://scottstuff.net/blog/articles/2005/10/24/the-great-typo-memory-leak for details.

Change History

10/24/05 17:51:06 changed by htonl

Could you provide the version numbers for your web server and fastcgi bindings? I'm trying to reproduce this, but am not showing the increase in size but a plateu (see http://ibook.lunchboxsoftware.com/compleak .png) (pardon my breaking the URL, the wiki engine in trac retardedly tries to render it as an img tag). Thanks!

10/24/05 18:08:22 changed by scott@sigkill.org

This is Apache 2.0.54 and mod_fastcgi 2.4.2, both from Debian.

I think the leak is proportional to the size of the page. It was growing faster with earlier testing, but the version posted takes a while to really grow--it starts around 16M for me, and then jumps to 21M after a couple hits (presumably loading the rest of Rails and allocating a few objects). Then it continues growing slowly. After 3,000 hits or so (using apachebench now, it's faster), I'm up to 45 MB.

This is with two dispatch.fcgis running, in static FastCGI mode:

FastCgiServer /var/www/typo/public/dispatch.fcgi -idle-timeout 120 -initial-env RAILS_ENV=production -processes 2

10/24/05 18:10:15 changed by scott@sigkill.org

FWIW, all of the process sizes quoted are RSS, not VM size.

10/24/05 18:27:42 changed by htonl

Thanks, Scott. Looks like I wasn't hitting it enough to trigger the problem, doing some more investigation ...

10/24/05 18:36:06 changed by htonl

By the way, it makes total sense that the rate of increase (which I am seeing now, after ~1000 hits) is proportional to the page size. The response object (which contains the full body of the page) is dup'ed in components.rb and if it's not being properly GCed, then your experience seems to fit in with that.

10/24/05 21:31:43 changed by htonl

The problem is the after filter I added a while back to avoid clobbering the flash for components. Removing that totally flattens the memory usage, so I'll come up with a new solution for that problem tonight and things should get back to normal. Thanks for the ticket!

10/24/05 23:20:45 changed by nzkoz

  • owner changed from David to htonl.

10/25/05 00:40:44 changed by htonl

  • status changed from new to closed.
  • resolution set to fixed.

This should now be fixed by [2722].