[jira] [Created] (JENA-689) Fuseki/TDB memory leak for concurrent updates/queries

["Ola Bildtsen (JIRA)" <ji...@apache.org>]

Ola Bildtsen created JENA-689:
---------------------------------

             Summary: Fuseki/TDB memory leak for concurrent updates/queries
                 Key: JENA-689
                 URL: https://issues.apache.org/jira/browse/JENA-689
             Project: Apache Jena
          Issue Type: Bug
          Components: Fuseki, TDB
    Affects Versions: TDB 1.0.1, Fuseki 1.0.1
         Environment: OSX 10.9.2, 2.8 GHz, 16G RAM, SSD
and CentOS release 6.4, x86_64, 64G RAM, SSD
            Reporter: Ola Bildtsen


When running concurrent POST updates and queries against a Fuseki/TDB server, the server appears to bleed memory until it eventually runs out and dies with:

{{java.lang.OutOfMemoryError: GC overhead limit exceeded}}

Using the included TDB config file, sample data file, and Groovy script, the Fuseki/TDB server can consistently be knocked down.  The script runs four concurrent threads: one that repeatedly POSTs data (in separate contexts/graphs) and three that query the server for triple counts.

To execute the script, do the following:

# Install Groovy
# Download and install jena-fuseki-1.0.1
# Download the attached file and untar it in the jena-fuseki directory
# Edit the {{fuseki-server}} script, set the max heap size to 2G {{(--Xmx2G)}}
# Start the server with: {{./fuseki-server --config=config-test.ttl}}
# In a separate window/shell, execute: {{groovy query.groovy}}
# Wait a few minutes for the OOE to occur.  The script will output some stats.

While this simple test fails consistently on OSX and running with a 2G heap Fuseki/TDB server, we've also observed it running on CentOS with a 16GB heap max and monitoring with NewRelic.  It took a lot longer, but the end result was the same: all the heaps (regular, eden, survivor, and old gen) eventually converge on their maximums and the JVM fails.



--
This message was sent by Atlassian JIRA
(v6.2#6252)