On 16.1.2013 2:32, Devlin, Alex wrote:
Hello,
We're using OpenGrok 11.1 with a Perforce repository and Tomcat 6.
Unfortunately, we also have a memory leak in the application. It
sporadically crashes with very little warning beforehand; the server's
swap memory usage gradually starts rising about 3 hours before it uses
100% of the system memory. We applied the bugfix located at
http://defect.opensolaris.org/bz/show_bug.cgi?id=19215
<http://defect.opensolaris.org/bz/show_bug.cgi?id=19215> but it did
not resolve the issue...
Get to 0.11.1 , I think no reindex needed, it should contain some fixes
we use 0.11.1 inhouse (not with perforce, but with 4 other scms) and
don't see any of this afaik (Vlada, any comments from your side?)
Right now we think it's some kind of thread leaking issue. When
Tomcat's shutdown.sh is called, there will often be several dozen
messages in the log files similar to the following:
Message was "SEVERE: The web application [/source] created a
ThreadLocal with key of type
[org.opensolaris.opengrok.configuration.RuntimeEnvironment$1] (value
[org.opensolaris.opengrok.configuration.RuntimeEnvironment$1@20a594d3]) and
a value of type [org.opensolaris.opengrok.configuration.Configuration]
(value
[org.opensolaris.opengrok.configuration.Configuration@56cdb963]) but
failed to remove it when the web application was stopped. This is very
likely to create a memory leak."
check on tomcat docs, but this doesn't really point to leak, it just
means we persist objects for configuration (which are rather small,
unless Jens changed something more there)
I'd really start with 0.11.1, if still the problem will be there(I am
aware about another "leak", but not such as you describe and it's caused
by bug in lucene it seems, hope Alan will clarify here)
then I'd move to jmap, jhat, etc. (I think eclipse has mat or something
like that to analyze leaks) and do some more investigation, but I
vaguely remember we fixed something like this in 0.11.1
- the other thing is to give the webapp container more JVM memory, I
think the Oracle internal big opengrok service runs with 4G for the
container
(I hope we can lower these insane memory requirements by improving
analyzers in next version and stop caching whole files in memory)
xing the fingers
L
Any and all advice would be much appreciated. We're attempting to
locate the leak, but have not yet had much luck.
Thanks,
-Alex
_______________________________________________
opengrok-discuss mailing list
opengrok-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opengrok-discuss
_______________________________________________
opengrok-discuss mailing list
opengrok-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opengrok-discuss
