l*****b
发帖数: 82 | 1 Hi, friends,
I have production env with JBoss 4.0.4 and was add ehcache in last release.
BUt it was slow down and then shutdown due to the java heap out of memory in
every 20 days after that and need reboot the jboss. So far, I have not
found the root cause, just got some symptons: java heap usage is overflow, e
.g. over 512 max to 6xx sometime, seems run out memory. But it is ok in the
19 days when I monitor the memory usage, usually have about 120 - 150M free
memory left. Do you have any idea or experience on my case?
The specs:
JBoss 4.04
Java 1.5.0.07
server physical mem: 1G
Thanks |
g*****g
发帖数: 34805 | 2 Likely a memory leak, dump the threads every few hours to see if you
can get a clue.
.
in
e
the
free
【在 l*****b 的大作中提到】
: Hi, friends,
: I have production env with JBoss 4.0.4 and was add ehcache in last release.
: BUt it was slow down and then shutdown due to the java heap out of memory in
: every 20 days after that and need reboot the jboss. So far, I have not
: found the root cause, just got some symptons: java heap usage is overflow, e
: .g. over 512 max to 6xx sometime, seems run out memory. But it is ok in the
: 19 days when I monitor the memory usage, usually have about 120 - 150M free
: memory left. Do you have any idea or experience on my case?
: The specs:
: JBoss 4.04
|
l*****b
发帖数: 82 | 3 Thank for the direction, goodbug. I will try it. |
l*****b
发帖数: 82 | 4 Hi, Goodbug,
I encountered the heap overflow issue again and got the thread dump logs.
Seems I did not see special exception. But One thing I remembered I add new
ehcache/jgroup components in the JBoss which seems has some conflict with
the built-in jboss clustering components (the old jgroup libs). I am not
sure it is the clue I could start with. |
g*****g
发帖数: 34805 | 5 Use "Memory Analyzer" (MAT) to analyze your .hprof file,
you should be able to see what's eating your memory, regardless
your libraries.
I should have said heap dump, not thread dump, sorry for the
confusion.
new
【在 l*****b 的大作中提到】
: Hi, Goodbug,
: I encountered the heap overflow issue again and got the thread dump logs.
: Seems I did not see special exception. But One thing I remembered I add new
: ehcache/jgroup components in the JBoss which seems has some conflict with
: the built-in jboss clustering components (the old jgroup libs). I am not
: sure it is the clue I could start with.
|
l*****b
发帖数: 82 | 6 Oh, no problem, thanks for your professional remind. |
b******y
发帖数: 1684 | 7 what's the best memory profiler? MAT?
【在 g*****g 的大作中提到】
: Use "Memory Analyzer" (MAT) to analyze your .hprof file,
: you should be able to see what's eating your memory, regardless
: your libraries.
: I should have said heap dump, not thread dump, sorry for the
: confusion.
:
: new
|
g*****g
发帖数: 34805 | 8 I haven't been using commercial profiler for a while, jprofiler used
to be very good. MAT is good enough for me as I only need to look at
snapshot.
【在 b******y 的大作中提到】
: what's the best memory profiler? MAT?
|
l*****b
发帖数: 82 | 9 I used JProfiler to monitor the heap in JBoss server and found some
suspicious java.lang.Object instances are increased gradually but cannot see
what type exactly they are. I really assume it is the cause leading to 20-
day heap memory leaking. Do we have any better idea how to get more into it?
or any other way or tool?
Thanks |
g*****g
发帖数: 34805 | 10 That's weird, the profiler should be able to expose their
implementation types. Take a heap dump and try MAT.
see
it?
【在 l*****b 的大作中提到】
: I used JProfiler to monitor the heap in JBoss server and found some
: suspicious java.lang.Object instances are increased gradually but cannot see
: what type exactly they are. I really assume it is the cause leading to 20-
: day heap memory leaking. Do we have any better idea how to get more into it?
: or any other way or tool?
: Thanks
|
b**l
发帖数: 25 | 11 I believe these objects are elements stored in ehcache memory store. And it
really depends on which version of
Ehcache you are using. The same issue happened in my project when I upgraded
ehcache to 1.8.
You can try to add this java parameter in your start up script,
-Dnet.sf.ehcache.use.classic.lru=true
Good luck,
see
it?
【在 l*****b 的大作中提到】
: I used JProfiler to monitor the heap in JBoss server and found some
: suspicious java.lang.Object instances are increased gradually but cannot see
: what type exactly they are. I really assume it is the cause leading to 20-
: day heap memory leaking. Do we have any better idea how to get more into it?
: or any other way or tool?
: Thanks
|
l*****b
发帖数: 82 | 12 Good advice, I will try. Thanks.
【在 g*****g 的大作中提到】
: That's weird, the profiler should be able to expose their
: implementation types. Take a heap dump and try MAT.
:
: see
: it?
|
l*****b
发帖数: 82 | 13 Maybe it is the cause. I am currently using Jboss 4.0.4 GA and Jgroup 2.6.14
.GA jar. I will try this way and the monitor tool goodbug suggest to see
more details.
Thanks
it
upgraded
【在 b**l 的大作中提到】
: I believe these objects are elements stored in ehcache memory store. And it
: really depends on which version of
: Ehcache you are using. The same issue happened in my project when I upgraded
: ehcache to 1.8.
: You can try to add this java parameter in your start up script,
: -Dnet.sf.ehcache.use.classic.lru=true
: Good luck,
:
: see
: it?
|
