-
Type:
Improvement
-
Resolution: Done
-
Priority:
Major - P3
-
Affects Version/s: 2.4.5
-
Component/s: JavaScript
-
None
-
Environment:Windows+Linux, MongoDB 2.4.5
-
Minor Change
ISSUE SUMMARY
Excess memory consumption due to over aggressive caching of V8 Isolates.
USER IMPACT
This can present as what appears to be a memory leak when many long lived connections have used any javascript at any point (MapReduce, $where, db.eval(), group). It is present in versions of MongoDB prior to and including v2.4.6.
SOLUTION
Switched to a fixed size cache, rather than a per connection cache.
WORKAROUNDS
There are a few workarounds.
- End connections which have used javascript
- Only run javascript on as small a subset of connections as possible
PATCHES
Production release v2.4.7 contains the fix for this issue, and production release v2.6.0 will contain the fix as well.
Original Description
Each connection that uses server-side Javascript allocates a personal scope-local heap 512MB block of address space, while using under 1MB of it (+32MB block with 1MB committed memory).
512+32MB blocks are allocated per JS query type (M/R, eval, etc.).
These blocks seems to be deallocated only after connection close (even if this connection no longer runs server-side js).
We should make that heap global or reduce the occupied VM space per connection. Right now the upper bound is 2GB x (number of connections), which can exhaust 8TB Windows Address space at 4K concurrent connections.
Temporary workaround would be to destroy the cache after server-side JS finishes, but it will introduce additional latency in the M/R-heavy environments.