[SERVER-10596] V8 cache data is not cleaned up in connection after usage Created: 21/Aug/13  Updated: 11/Jul/16  Resolved: 26/Aug/13

Status: Closed
Project: Core Server
Component/s: JavaScript
Affects Version/s: 2.4.5
Fix Version/s: 2.4.7, 2.5.3

Type: Improvement Priority: Major - P3
Reporter: Alexander Komyagin Assignee: Mathias Stearn
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows+Linux, MongoDB 2.4.5


Issue Links:
Depends
Related
Backwards Compatibility: Minor Change
Participants:

 Description   
Issue Status as of October 23rd, 2013

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.

  1. End connections which have used javascript
  2. 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.



 Comments   
Comment by auto [ 27/Aug/13 ]

Author:

{u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}

Message: SERVER-10596 Globalize formerly per-thread Pool of JS Scopes

This ensures that the limit of 10 pooled scopes is actually enforced.
With a per-thread Pool, long-lived connections could cause very high
memory usage (both real and virtual) even if they haven't used JS in a
long time.

Manually fixed backport of commit 73841f7a1ec1322d96179eb2712ab438f56add00

Conflicts:
jstests/auth/js_scope_leak.js
src/mongo/db/auth/auth_external_state.h
src/mongo/db/auth/auth_external_state_d.cpp
src/mongo/db/auth/auth_external_state_d.h
src/mongo/db/auth/auth_external_state_s.cpp
src/mongo/db/auth/auth_external_state_s.h
src/mongo/db/auth/authorization_session.cpp
src/mongo/db/auth/authorization_session.h
src/mongo/db/commands/group.cpp
src/mongo/db/matcher/expression_where.cpp
src/mongo/scripting/engine.cpp
Branch: v2.4
https://github.com/mongodb/mongo/commit/5f724c01611a8c12da6b803b2edff97788a756c1

Comment by auto [ 26/Aug/13 ]

Author:

{u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}

Message: SERVER-10596 Globalize formerly per-thread Pool of JS Scopes

This ensures that the limit of 10 pooled scopes is actually enforced.
With a per-thread Pool, long-lived connections could cause very high
memory usage (both real and virtual) even if they haven't used JS in a
long time.
Branch: master
https://github.com/mongodb/mongo/commit/73841f7a1ec1322d96179eb2712ab438f56add00

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