Andrey, Thanks for the quick confirmation. We will have a look at the changes to the development branch and investigate upgrading our embedded db.
Regards, Chris On Friday, January 17, 2014 2:21:54 AM UTC-5, Andrey Lomakin wrote: > > Hi Chris, > Unfortunately you are right. But good news are: > 1. We do not use mvbtree in our new indexes (in 1.6.3 for sure) so we do > not use heap any more but direct memory disk cache, so it is impossible to > have OOM now and memory consumption is controlled > using storage.diskCache.bufferSize (in megabytes) > 2. Issue with listeners which you described has already fixed in develop > branch. > > > On Thu, Jan 16, 2014 at 11:17 PM, Chris Drake > <[email protected]<javascript:> > > wrote: > >> Hello, >> >> I'm investigating a OOME we are seeing with v1.5.1 of OrientDB embedded >> in our application. After reviewing a number of heap dumps when the issue >> has occurred, I can see that the heap is being consumed by a single >> instance of OMVRBTreeIndexEngine which accounts for ~600MB of the available >> 1GB heap. See the following: >> >> One instance of >> "com.orientechnologies.orient.core.index.engine.OMVRBTreeIndexEngine" >> loaded by >> "org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 @ >> 0x1a0b4e90" occupies 580,935,080 (66.95%) bytes. The memory is accumulated >> in one instance of >> "com.orientechnologies.orient.core.type.tree.OMVRBTreeDatabaseLazySave" >> loaded by >> "org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 @ >> 0x1a0b4e90". >> >> Keywords >> com.orientechnologies.orient.core.type.tree.OMVRBTreeDatabaseLazySave >> com.orientechnologies.orient.core.index.engine.OMVRBTreeIndexEngine >> org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 @ >> 0x1a0b4e90 >> >> After reviewing a number of heap dumps, I noticed that the >> OMemoryWatchDog instance is losing all of the registered listeners. >> Testing seems to indicate that shortly after startup triggering one or more >> GCs will cause the registered listeners to 'dissapear'. After reviewing the >> code I believe the issue is related to the introduction of the WeakHashMap >> used to track the listeners. The problem appears to be that when inserting >> a listener into the Map a new instance of ListenerWrapper() is being passed >> directly to WeakHashMap.put(). Since GC'ing of the entries within the map >> is performed based on references to the key, and no other references are >> maintained except by the WeakHashMap itself I believe the entries are being >> GC'd prematurely. >> >> Does this sound reasonable? I found a separate >> thread<https://groups.google.com/forum/#!msg/orient-database/qyr6PyTuYQ8/D5OVWXR02Y8J>which >> seems to discuss a similar issue however I could not find a >> correlation between the call to callOnCloseListeners() and the >> de-registering of the OMemoryWatchDog listeners. >> >> Thanks and looking forward to any feedback you may have. >> >> Regards, >> Chris >> >> -- >> >> --- >> 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 [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Best regards, > Andrey Lomakin. > > Orient Technologies > the Company behind OrientDB > > -- --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
