Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-10596

V8 cache data is not cleaned up in connection after usage

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 2.4.5
    • Fix Version/s: 2.4.7, 2.5.3
    • Component/s: JavaScript
    • Labels:
      None
    • Environment:
      Windows+Linux, MongoDB 2.4.5
    • Backwards Compatibility:
      Minor Change

      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.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: