Released OrientDB 2.0.6 (hotfix)

[Luca Garulli]

Hi all,

OrientDB Team just released OrientDB v. 2.0.6 (hotfix). Please upgrade your OrientDB v. 2.0.x, binary compatibility is guaranteed.

What has been fixed? https://github.com/orientechnologies/orientdb/issues?q=milestone%3A2.0.6+is%3Aclosed.

Download it from: http://www.orientechnologies.com/download/ or update your Maven pom.xml:

<dependency>
  <groupId>com.orientechnologies</groupId>
  <artifactId>orientdb-graphdb</artifactId>
  <version>2.0.6</version>
</dependency>

Lvc@

[Mark H.]

Hi,

If I currently have v2.0.5, what's the bet way to upgrade without losing data?

Do I have to export and import the data from v2.0.5 to v2.0.6?

Thanks.

[Colin]

Hi Mark,

The upgrade is binary compatible with 2.0.5.

So, no export/import should be required.

When in doubt, backup first.  ;-)

-Colin

Orient Technologies

The Company behind OrientDB

[Mark Hansom]

So what is the process for upgrading to binary compatible version?

Do I simply install v2.0.6 up and running then copy some data files?

Thanks!

--

---
You received this message because you are subscribed to a topic in the Google Groups "OrientDB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/orient-database/x6TiK-X-bNE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Colin]

Install 2.0.6.  Copy your specific folders from 2.0.5's databases/ into 2.0.6's.  Then start 2.0.6's server.sh/.bat as appropriate.

-Colin

[Fábio Costa]

Any news regarging performance? I'm suffering a lot with Out of Memory errors...

[Luca Garulli]

Which OOM errors? Could you report them? Could you also post OrientDB version and your server hw/sw configuration?

Thanks,

Lvc@

--

---
You received this message because you are subscribed to the Google Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orient-databa...@googlegroups.com.

[Fábio Costa]

Issue:

At some unpredictable point in time, my application suddenly start consuming a lot of memory, leading to memory issues.

It's so strange. My application in general terms turns an XML into a graph. There are several files that represent a particular version, for each one I read the nodes and save as vertices. Hierarchy and explicitly defined relationships are stored as edges. It starts ok, with a reasonable processing time. Let's say that it takes from 5 to 15 minutes to process a file.

Then the problem appears without no apparent reason. I file takes 1,5 hours to process and the next throws Out of Memory after 3 or 4 hours. Right now I have one which is running for more than two hours(why?). 

I made almost every tuning described at the site, apart from defining the vertex classes before hand. I don't want to control the schema, so I didn't go through this point. 

I can share my application if you want, but it's not open so I can't post in the group. If you have a Bitbucket it would be easier to share.

OrientDB version: 2.0.5

Enviromnent: Amazon EC2, m3 large, with Amazon AMI 

Software configuration: tried plocal and remote, both throws Out of Memory. Apart from the server script, I have increased the socket timeout.

Server config:

LOG_FILE=$ORIENTDB_HOME/config/orientdb-server-log.properties

WWW_PATH=$ORIENTDB_HOME/www

ORIENTDB_SETTINGS="-Dprofiler.enabled=true"

JAVA_OPTS_SCRIPT="-Djna.nosys=true -XX:+UseConcMarkSweepGC -Djava.awt.headless=true -Dfile.encoding=UTF8 -Drhino.opt.level=9"

# ORIENTDB MAXIMUM HEAP. USE SYNTAX -Xmx<memory>, WHERE <memory> HAS THE TOTAL MEMORY AND SIZE UNIT. EXAMPLE: -Xmx512m

MAXHEAP=-Xmx4096m

# ORIENTDB MAXIMUM DISKCACHE IN MB, EXAMPLE, ENTER -Dstorage.diskCache.bufferSize=8192 FOR 8GB

MAXDISKCACHE=-Dstorage.diskCache.bufferSize=8192

exec "$JAVA" $JAVA_OPTS $MAXHEAP $JAVA_OPTS_SCRIPT $ORIENTDB_SETTINGS $MAXDISKCACHE -Djava.util.logging.config.file="$LOG_FILE" -Dorientdb.config.file="$CONFIG_FILE" -Dorientdb.www.path="$WWW_PATH" -Dorientdb.build.number="UNKNOWN@r${buildNumber}; 2015-03-12 22:59:10+0000" -cp "$ORIENTDB_HOME/lib/orientdb-server-2.0.5.jar:$ORIENTDB_HOME/lib/*" $* com.orientechnologies.orient.server.OServerMain

--

---
You received this message because you are subscribed to a topic in the Google Groups "OrientDB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/orient-database/x6TiK-X-bNE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to orient-databa...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Systems Analyst
Sun Certified Programmer for the Java Platform, Standard Edition 5
Sun Certified Business Component Developer for the Java Platform, Enterprise Edition 5

[Luca Garulli]

Hi Fabio,

If you attach a profiler to the JVM that is running OrientDB, which kind of memory is kept? You could use jvisualvm (bundled with JVM) or better YourKit (free trial version).

Lvc@

[Fábio Costa]

I will try it later and tell you. 

[Fábio Costa]

The hprof file is just too big to send here, but I attached a screenshot of Visual VM. I'm not surprised that the OrientDB classes are the ones with more instances, what is strange is the classes OrientGraphoNoTx and OrientConfigurableGraph.Settings with more than 3 million instances each. I'm using the factory, not creating new instances. From this simple analysis, it seems we have to share the OrientGraphoNoTx instance among with all methods that perform CRUD operations instead of using the factory. What do you think?