-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
suspect memory leak in gmongo 1.0 #20
Comments
Hello Bruno, Not since version 0.7.x. You end up with a java.lang.OutOfMemoryError? Can you reproduce that? Tks. |
Hi, I took heapdump after a fresh startup and warmup, and an heapdump when the Those entries are generated by groovy AST @DeleGate but strangely enough I had a look to GMongo code and I didn't spot anything obviously wrong, Bruno On Thu, May 16, 2013 at 7:54 AM, Paulo Gabriel Poiati <
|
I see, You have a lot of ExpandoMetaClass with references to DBApiLayer? Weired, you should not have a lot o DBApiLayers instance in your VM. What is your environment? How much collections your App. uses? DBCursor patching can lead to the creation of ExpandoMetaClass instances, This is due to my patching approach, not really optimised (but the GC should do the job). Can you give me the output of the JVM heap? I did an stress test of a day. I ran one heavy load script for 24 hours and got no memory error. But of course this don't invalidate a possible leak. Tks Bruno. |
Hi, just to be clear, as I wrote in the first email the leaked instances are not DBApiLayer but MetaMethodIndex instances (several hundreds of thousands) for the same class In your test did you try to make an heap dump towards the end and run Eclipse Memory Analyzer? (http://www.eclipse.org/mat/) The leaked size is very small so it might take long time before OOM occurs. Just before shutting down the test, take a heap dump and run the analyzer. My environment is a Groovy/Grails app deployed in Tomcat 7 and running on multiple EC2 micro instances. Bruno |
Bruno, Micro instances are really not optimal for the JVM, can you try in a small instance instead? |
Hi, The decision of using Micro instances of the websites is obviously a cost-driven decision. I can confirm that the issue is somewhere in the way GMongo uses the driver. Because due to its instability, To make sure that the comparison was fair, I kept running one instance of the webserver with the gmongo wrapper and started it more or less at the same time of the one that was using the java driver directly. Thanks anyway to have spent some time to look at the issue. |
Ok Bruno, I will try to reproduce this again later. Tks for your time too. |
@poiati Was this problem solved? I'm using Gmongo 1.2 and suffering from a memory leak, too. When looking at the heap dump, it appears to be very similar to this issue. Any ideas what could cause such leaks when using Gmongo? These are the leak suspects:
|
@poiati I created a simplistic job in a brand new grails application (
The only other additions to the new project were This time, the leak suspects are these:
|
Hello troxler, Other people already reported memory problems with GMongo before, but he couldn’t reproduce the problem in a controlled environment. I think your test may not configure a problem because of the laziness of the Java GC. If you let the application run for several hours, it crash? Said that. Yes, maybe there is a problem between Groovy ExpandoMetaClass and GMongo implementation, but there is no hint of what it can be. Your help is really appreciated. Thanks. |
Thanks for the update. Yes my application crashed after running for several hours (
Before generating a heap dump, I always forced garbage collection from within VisualVM which did not decrease the consumed heap a lot (but more than it did by itself). |
As far as I know, you can’t force Java GC, you can only request. Anyway, if it crash, probably there is a problem. I will ran your How much time it usually takes to crash? Tks. []'s blog.paulopoiati.com On Wed, Dec 11, 2013 at 11:30 AM, troxler notifications@github.com wrote:
|
Ah yes. When running my real application, it sometimes also crashed because it was doing more garbage collection than anything else when it was approaching the maximum heap space. So I do not think that the lazyness of GC is the problem.
That depends on the amount of heap space you allocate ;) As the consumption is about 450MB after an hour, I guess the application would crash after approximately an hour with a heap space of 400MB. In this test application, however, I did not wait until it crashed.
Thanks a lot for looking into it. |
I took a closer look to the problem. Your application uses multiple GMongo instnances? Usually you need only one instance per application. Here is your code with the above in mind: import com.gmongo.GMongo
import com.mongodb.MongoURI
class MemoryJob {
def concurrent = false
static triggers = {
simple startDelay: 5000, repeatInterval: 200
}
static mongoUrl = "mongodb://localhost:27017"
static mongo = new GMongo(new MongoURI(mongoUrl))
static db = mongo.getDB("memory");
def execute() {
println new Date()
db.getCollection("test").insert(['date':new Date()])
}
} This leaks to you too? |
Thanks for the suggestion. And indeed it solved the memory problems I was having in my application. It has now been running for several hours and the memory consumption has been constant. So thank you :) Maybe this is something that should be looked into in the future anyway, though. |
You are welcome. And, yes, this should looked forward. []'s blog.paulopoiati.com On Thu, Dec 12, 2013 at 1:06 PM, troxler notifications@github.com wrote:
|
Hi,
I'm experiencing memory leaks since I started to use gmongo.
I read few mailing list post that you already identified and fixed a memory leak in v.0.7-0.8
The Eclipse Memory Analyzer identifies the following leak:
Looking at the heapdump those instances of ExpandoMetaClass is then holding MetaMethodIndex instances (several hundreds of thousands) for the same class
"DBApiLayer$MyCollection" and "DBCursor" with one set of methods of every method in the driver api.
My suspect is that the groovy delegates are continuously generated (multiple times) and retained by the class loader, so that you have multiple times the same delegates generated over and over for the same target Class.
Have you came across this problem?
regards
Bruno
The text was updated successfully, but these errors were encountered: