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]>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]. > 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.
