Redian新闻
>
JBoss 4.0.4 is slow down in every 20 days
avatar
JBoss 4.0.4 is slow down in every 20 days# Java - 爪哇娇娃
l*b
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
avatar
g*g
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

avatar
l*b
3
Thank for the direction, goodbug. I will try it.
avatar
l*b
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.
avatar
g*g
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.

avatar
l*b
6
Oh, no problem, thanks for your professional remind.
avatar
b*y
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

avatar
g*g
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?
avatar
l*b
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
avatar
g*g
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

avatar
b*l
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

avatar
l*b
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?

avatar
l*b
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?

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。