couzteau wrote : I'm guessing that a garbage collector thread crashed.
I doubt that a thread crashed - the JVM would have taken a dump if it did.
But I would guess that you are hitting a major garbage collection. A major
collection on a 2GB heap will take a long time, and with a parallel collect
Hi Peter,
Thank you very much. I have question right away:
anonymous wrote : Another thing you could do - when this slowdown hits, take a
JVM thread dump and look at which threads are running and what they are doing.
How do I take a thread dump?
I tried kill -SIGQUIT pid but that didn't do anyth
The kill should do it - the output goes to stderr (I think, it could be stdout)
for the JVM. If you ran JBossAS as a service, the service start script probably
redirects stdout/stderr to a file, look there.
If you ran JBossAS from a terminal, you can enter CTRL-\ in that terminal to
get it.
Vi
anonymous wrote : The kill should do it
Thanks for insisting.
It dumps to the terminal where the process was started from. So when I logout
and re connect using SSH I don't know (yet) how to capture the dump.
If you (or anyone) has an idea I would be grateful if you shared it.
Another directio
jstack does the job of creating memory dumps.
jstack pid
is all it takes.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173210#4173210
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173210
___
I now have a few thread dumps, but I'm not quite sure what to look for. I
always have about 115 threads out of which about 33-38 are RUNNABLE. 32-34 are
in state TIMED_WAITING, 32-34 are WAITING.
Correct me if I'm wrong, but I assume the thread or the threads that are
burning CPU must be in st
One thing to look for is if, over several thread dumps, certain threads are
still working on the same code - this could indicate an infinite loop.
Another thing to look for is if certain code always show up as being the active
code, though in different threads. This could identify code that coul
Thank you, Peter. I will follow up when I have news.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177268#4177268
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4177268
___
jb
Hi couzteau.
You can analyse the behaviour by gc with hpjmeter is a tool free.
How does the gc work you can choose algorithm different in java.
You can refer at this url http://java.sun.com/docs/hotspot/gc1.4.2/faq.html
Or you can increase the number of jboss managing your application
View the
Thanks everyone. Your help is much appreciated. I was able to identify the root
cause of the problem. It wasn't the GC, but actually a query that was
overwhelming the hardware.
I wonder if I can set the timeout for the transactional context in JBoss.
View the original post :
http://www.jboss.c
Thanks for your help. I was able to determine which threads were causing the
slowdown. It wasn't GC, but a query that was overwhelming the resources.
Peter, thanks for getting me on the right track to nail this down.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopi
11 matches
Mail list logo
