[SERVER-3528] memory footprint of JS context keeps increasing as it is used Created: 03/Aug/11  Updated: 12/Jul/16  Resolved: 15/Nov/11

Status: Closed
Project: Core Server
Component/s: JavaScript
Affects Version/s: None
Fix Version/s: 2.0.2, 2.1.0

Type: Bug Priority: Major - P3
Reporter: Antoine Girbal Assignee: Antoine Girbal
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
Operating System: ALL
Participants:

 Description   

This was easily reproducible with M/R.
The easy workaround is to disable JS scope caching.
In scripting/engine.cpp, line 266:

if ( l.size() > 10 )

{ delete s; }

for

if ( true )
delete s;
}

It could be due to:

  • us not doing cleanup of certain JS objects, but then we would hit an OOM from JS
  • JS objects that are very small but point to large BSON data that is not reclaimed. Still should be cleared when GCing.
  • leak / fragmentation in SM heap.


 Comments   
Comment by auto [ 15/Nov/11 ]

Author:

{u'login': u'agirbal', u'name': u'agirbal', u'email': u'antoine@10gen.com'}

Message: SERVER-3528: memory footprint of JS context keeps increasing as it is used, delete every 100 use
Branch: v2.0
https://github.com/mongodb/mongo/commit/84a3d7aa3dcb9aef261a365daa862d82d1ba513e

Comment by Antoine Girbal [ 15/Nov/11 ]

reopen for backport

Comment by Antoine Girbal [ 22/Oct/11 ]

it would be great to backport to 2.0.
Many people will hit OOM from JS at some point without this fix.

Comment by Antoine Girbal [ 19/Sep/11 ]

scopes are now only cached for 100 uses.
Verified that mem usage stays constant.

Comment by auto [ 19/Sep/11 ]

Author:

{u'login': u'agirbal', u'name': u'agirbal', u'email': u'antoine@10gen.com'}

Message: SERVER-3528: memory footprint of JS context keeps increasing as it is used, delete every 100 use
Branch: master
https://github.com/mongodb/mongo/commit/02e37cb0218dc70f8d6fa27966b25f31ddc355d7

Comment by Antoine Girbal [ 19/Aug/11 ]

Another workaround is to close connections regularly from the client side.
Or just use a new connection for each M/R job, for example by calling a new "mongo" process.
This is obviously not ideal but ok for long batch jobs.

Comment by Antoine Girbal [ 03/Aug/11 ]

not fixed

Generated at Thu Feb 08 03:03:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.