I'm not JF (nor do I play him on TV), but I'll weigh in with a few
observations.
In the stacks I saw, either all threads are just waiting (as Kedar
mentions), or most threads are waiting and a few are blocked reading
from the database. None of those threads would be causing CPU to be
used, nor would that slow down accessing static resources. [It could
mean that requests that need to go to the database are slow; the fact
that threads are either idle or reading from the database but not doing
anything else indicates that is a potential problem, but not necessarily
so either.]
When the OS reports that CPU is being used and it doesn't show up in
jstacks with threads actually running (in the RUNNABLE state, but not in
socketRead0), it typically means that the GC threads are running and
using the CPU. It would be good to use jstat to monitor how much time GC
(or use -Xloggc:gc.log in the domain.xml, which will print out the GC
usage to config/gc.log, which you can tail and see when GC is running).
If GC is spending more than a few % of total time, that's an issue, and
I'd guess that the hibernate cache is causing memory pressures.
The spinning poll issue JF mentioned earlier in the thread is still a
possibility in my mind if CPU is 100% utilized; I didn't see any
discussion of that specifically.
-Scott
On Wed, 2009-03-25 at 06:55 -0700, glassfish_at_javadesktop.org wrote:
> I don't see anything suspicious in your domain.xml.
>
> In your stack dump however, *all* the 150 Grizzly threads are just waiting for someone to notify
> them, since everyone grabs the pipeline and goes back to waiting state. JF, do you have any
> comment on that?
>
> -Kedar
> [Message sent by forum member 'km' (km)]
>
> http://forums.java.net/jive/thread.jspa?messageID=338958
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net