Defect #9730

Redmine leaks memory over 1G, YAML

Added by Stefan de Konink almost 6 years ago. Updated almost 6 years ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Ruby support
Target version:-
Resolution:Cant reproduce Affected version:1.2.2

Description

It isn't very difficult to find memory leaks in Redmine. Sadly everything that remotely points to a solution - the port of Redmine to 1.9.2 for example - looks abandoned.

Still these leaks make Redmine in practice unusable.

http://redmine.ruby-lang.org/issues/4832

valgrind.txt Magnifier (32.4 KB) Stefan de Konink, 2011-12-06 21:47


Related issues

Blocked by Redmine - Feature #4050: Ruby 1.9 support Closed 2009-10-18

History

#1 Updated by Etienne Massip almost 6 years ago

  • Category changed from Rails support to Ruby support
  • Resolution set to Invalid

I don't remember having heard or seen of such an issue in forum.

I close this issue since this is a Ruby issue, not a Redmine one.

Finally, the port of Redmine to Ruby 1.9 (#4050) is not abandoned.

#2 Updated by Stefan de Konink almost 6 years ago

Ignoring the fact that the memory leaks on my exist, doesn't change that YAML is leaking in Ruby. Moving this bug as a problem of Ruby shows that the fact that #4050 should be a blocker for this bug, making this bug valid.

#3 Updated by Etienne Massip almost 6 years ago

To be clear, I didn't say it does not exist, but there is no work to go at Redmine end and it's not worth it keeping it open for user information since this issue has (almost) never been reported.

Nevertheless, I concede that #4050 is a blocker.

#4 Updated by Stefan de Konink almost 6 years ago

So what is your suggestion?

Follow the ads saying you can get a hosted solution for $9 per month?

Or is there a way I can show that within 2 hours in valgrind the consumed memory rises to an insane point for a 'full featured bugtracker'?

#5 Updated by Etienne Massip almost 6 years ago

Well, it seems that this memory leak is about psych library which is the default YAML parser for Ruby1.9, which is not supported by Redmine.

So I don't get you: what's your configuration, could you please give details (see SubmittingBugs).

#6 Updated by Stefan de Konink almost 6 years ago

About your application's environment
Ruby version 1.8.7 (i686-linux)
RubyGems version 1.8.10
Rack version 1.1
Rails version 2.3.14
Active Record version 2.3.14
Active Resource version 2.3.14
Action Mailer version 2.3.14
Active Support version 2.3.14
Application root /var/lib/redmine
Environment production
Database adapter postgresql
Database schema version 20110511000000

About your Redmine plugins
Contacts plugin 1.1.5
Redmine Backlogs master branch (unstable)

#7 Updated by Jean-Philippe Lang almost 6 years ago

How do you know that your problem is related to http://redmine.ruby-lang.org/issues/4832? I personnaly do not experience memory leaks on redmine.org. The memory consumption of my ruby processes is pretty stable.

#8 Updated by Stefan de Konink almost 6 years ago

Since valgrind really gives a gazzilion lines of output. I specifically ask you to look at the last part; syck_parse for example.

For us it is so easy to reproduce... that I really have to abort at the 3rd request or so otherwise ruby goes above 1GB of memory.

#9 Updated by Jean-Philippe Lang almost 6 years ago

==3546== LEAK SUMMARY:
==3546==    definitely lost: 74,748 bytes in 858 blocks
==3546==    indirectly lost: 6,028 bytes in 137 blocks
==3546==      possibly lost: 2,402,632 bytes in 103,591 blocks
==3546==    still reachable: 256,202,523 bytes in 4,673,369 blocks
==3546==         suppressed: 0 bytes in 0 blocks

74KB lost / 256MB still reachable ?

#10 Updated by Stefan de Konink almost 6 years ago

Yes. The memory consumption of valgrind is quite higher than normal.

This is redmine after a few clicks without valgrind:
3608 redmine 20 0 211m 199m 3424 S 0.0 19.7 0:17.80 ruby

#11 Updated by Stefan de Konink almost 6 years ago

3608 redmine 20 0 258m 246m 3424 S 1.0 24.3 0:20.46 ruby

And after another click +50MB

#12 Updated by Jean-Philippe Lang almost 6 years ago

  • Priority changed from Urgent to Normal
  • Resolution changed from Invalid to Cant reproduce

My point is that this valgrind log doesn't illustrate the problem you described (1GB after 3 clicks). Anyway, this is not happening to everyone so there must be something else than this flaw in ruby1.8.7.

Feel free to post additional information that would help in reproducing your problem.

Also available in: Atom PDF