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

V8 cache data is not cleaned up in connection after usage

    • Type: Icon: Improvement Improvement
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 2.4.7, 2.5.3
    • Affects Version/s: 2.4.5
    • Component/s: JavaScript
    • Labels:
    • Environment:
      Windows+Linux, MongoDB 2.4.5
    • Minor Change

      Issue Status as of October 23rd, 2013

      Excess memory consumption due to over aggressive caching of V8 Isolates.

      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.

      Switched to a fixed size cache, rather than a per connection cache.

      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

      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.

            mathias@mongodb.com Mathias Stearn
            alex.komyagin@mongodb.com Alexander Komyagin (Inactive)
            0 Vote for this issue
            10 Start watching this issue