Details
-
Task
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
SERVER 0.4.0
-
None
-
None
-
2
-
SERVER 2014-12-17, SERVER 2014/12/31
Description
For SERVER-150, we're looking to add some logic which would call .terminate on ScriptingContainer instances in order to free up all of the associated memory that JRuby had allocated on behalf of the container. Hopefully, this is all we need to do to free up this memory, but it would be good to do some specific measurement to see what the effect of this is, i.e., to ensure that there's nothing else we need to do to free up memory and/or that JRuby isn't internally leaking memory.
For this effort, I was thinking of doing something like the following:
1) Using YourKit, take a memory snapshot of the running Java Puppet Master process.
2) New up a ScriptingContainer and JRubyPuppet instance within the container.
2) Simulate an agent catalog request through the instance.
3) Call terminate on the ScriptingContainer.
4) Repeat steps 1-3 some number of times.
5) Use YourKit generations feature to look for JRuby-related objects that survive across generations, e.g., memory created each generation which is never apparently freed, a sign that leaks may be present.
Attachments
Issue Links
- relates to
-
SERVER-273 Upgrade to JRuby 1.7.19 / fix for jruby-pool DELETE memory leak
-
- Closed
-
-
SERVER-150 Add functionality to JRuby service to trash instance
-
- Closed
-