Orientdb Java Heap Fehler

lief ich einen Test auf Orientdb 2.2.10TransnationaleGraphOrientdb Java Heap Fehler

Mit dem folgenden Sudo Code auf einzelnen Thread-System

for(i = 1 to 1000) 
{ 
    DB_Name = getRandomString() 

    createGraphDb(DB_Name) using OServerAdmin : if db do not exist 
    gFactory = OrientGraphFactory(DB_Name) : if db exist 


    graph = OrientGraphFactory.getTx() 
    previousEvent = null 

    for(j=1 to 1000) 
     { 
     currentEvent = getrandomString() 
     if(previousEvent and currentEvent != null) 
       { 
        - create Vertex named currentVertex and edges between them 
        - (from previous to current event) 
       } 
     else 
       { 
        create vertex named current event 
       } 
     previousEvent = currentEvent 
     } 
    graph.shutdown() 

}

Ich habe die folgende Ausnahme nach ein paar Iterationen meiner äußeren Schleife.

Exception in thread "Thread-0" java.lang.OutOfMemoryError: Java heap space 
at java.util.Arrays.copyOfRange(Unknown Source) 
at java.lang.String.<init>(Unknown Source) 
at java.lang.String.substring(Unknown Source) 
at java.lang.String.split(Unknown Source) 
at java.lang.String.split(Unknown Source) 
at com.orientechnologies.orient.core.config.OStorageConfiguration.fromStream(OStorageConfiguration.java:268) 
at com.orientechnologies.orient.core.config.OStorageConfiguration.fromStream(OStorageConfiguration.java:497) 
at com.orientechnologies.orient.core.config.OStorageConfiguration.load(OStorageConfiguration.java:207) 
at com.orientechnologies.orient.client.remote.OStorageRemote.open(OStorageRemote.java:330) 
at com.orientechnologies.orient.core.db.document.ODatabaseDocumentTx.open(ODatabaseDocumentTx.java:257) 
at com.orientechnologies.orient.core.db.OPartitionedDatabasePool$DatabaseDocumentTxPooled.internalOpen(OPartitionedDatabasePool.java:445) 
at com.orientechnologies.orient.core.db.OPartitionedDatabasePool.openDatabase(OPartitionedDatabasePool.java:308) 
at com.orientechnologies.orient.core.db.OPartitionedDatabasePool.acquire(OPartitionedDatabasePool.java:263) 
at com.tinkerpop.blueprints.impls.orient.OrientBaseGraph.<init>(OrientBaseGraph.java:144) 
at com.tinkerpop.blueprints.impls.orient.OrientTransactionalGraph.<init>(OrientTransactionalGraph.java:78) 
at com.tinkerpop.blueprints.impls.orient.OrientGraph.<init>(OrientGraph.java:135) 
at com.tinkerpop.blueprints.impls.orient.OrientGraphFactory.getTx(OrientGraphFactory.java:119)

Ist sie irgendein Problem mit meinem sudo-Code oder mit Orientdb.

Wenn ihre vorhandenen etwas besser, bitte vorschlagen.

Danke ..!

Quelle

2016-10-13 Prakash Pandey

Meine Heap-Größe ist -xmx512m. Was ist geeignete Heap-Größe für diese Art von Anwendung? –

Wie viele Gigs von RAM hast du zur Verfügung? Wenn Sie dem Java-Prozess beispielsweise maximal 8 GB zuweisen können, sollten Sie normalerweise kleinere Heapspeicher und große Festplattencachespeicher (Off-Heap-Speicher) zuweisen. Anstatt also:

java -Xmx8g ...

könnten Sie stattdessen versuchen, diese:

java -Xmx800m -Dstorage.diskCache.bufferSize=7200 ...

Weitere Einzelheiten entnehmen Sie die Seite in Bezug auf performance tuning on official documentation lesen kann.

Ich hoffe, es hilft.

Quelle

2016-10-13 13:12:59

Funktioniert der orientdb-Server auch auf JVM? Ich meine meine Datenbank läuft auf Remote-Maschine. Also, sprichst du über die Konfiguration der JVM meines Systems (in dem mein Java-Programm läuft) oder das des entfernten Systems, in dem orientdb läuft. –

Könnte Java-Heapspeicher-Problem auch in meinem Remotecomputer auftreten, auf dem orientdb "server.sh" ausgeführt wird, frage ich dies, weil mein Terminal in dem Orient ausgeführt wird, zeigt dies - >>>>>> "Fehler beim Ausführen der Anforderung java.lang.OutOfMemoryError: Java-Heap-Space " –

In OrientDB behalten die Transaktionen Änderungen im RAM, also wenn Sie Transaktionen mit hunderttausenden von Elementen haben, könnte dieses Problem verursachen. Ich schlage vor, Sie binden alle X Elemente ein. Ich schlage vor, mit 1000 zu beginnen und dann basierend auf dem Ergebnis zu tunen.

Quelle

2016-10-13 21:17:57 Lvca

Nach jeder inneren Iteration (for-Schleife), begehe ich db. graph.shutdown wird festgelegt, bevor die Grafikinstanz beendet wird. –

Hallo Ich testete den Client Java (8u102) mit 10 Schleifen und ich habe keinen OOM-Fehler gesehen, der 72 Minuten lang lief. Der Server startete nur Full GC, bei db Nummer 7, mit 700 Vertex, (0,2 Sekunden für volle, 0,5 Sekunden für App), aber langsam überlebte für weitere 30 Minuten, bis zu 10 db; Prozessgröße erhöht bis 7.8gb (und 485.2% CPU) Der Client-Prozess war nicht riesig (unter 2GB) anfordern niedrige CPU%, und ein FullGC (0.6s) nur einmal oder zweimal für jede db Sie brauchen mehr Max Heap auf dem Server (versuchen 1 GB) und eine Menge RAM (getestet mit 16 GB RAM und i7 auf OSX) Claudio –

Kann hinzufügen, dass Server war standardmäßig 512m Max Heap und Client 4GB Max Heap verwenden, aber es weniger als 1,5 verwendet gb –

können Sie prüfen, Heap-Nutzung mit -XX: + PrintGC -XX: + PrintGCDateStamps -XX: + PrintGCDetails -XX: + PrintGCTimeStamps -XX: + PrintTenuringDistribution -Xloggc: $ ORIENTDB_HOME/log/gc_% p_% t.log auf dem Server (kann das letzte XX-Flag nur für die Untersuchung über die Beförderung von neu nach alt hinzufügen).

Sie können ähnliche Einstellungen auf Ihrem Client hinzufügen (ändern Sie nur die Option gc.log). Ich habe gerade eine Java-Klasse (8u102 auf Mac, mit 16gb und i7), basierend auf Ihrem Pseudocode, aber 1 Schleife (1 db) mit 1000 Scheitel + Kanten ausgeführt und den Job ohne OutOfMemory

erfolgreich abgeschlossen Tschüss Claudio

Quelle

2016-10-14 16:13:37

Ich habe Heap-Fehler nach der 9. Schleife. –

Heap-Größe zur Verfügung gestellt ist 512m –

Orientdb Java Heap Fehler

Antwort

Verwandte Themen