JBoss: Windows vs Linux and a Solaris boot issue

Ryan Bowman ryanlbowman at gmail.com
Tue Mar 7 16:44:17 MST 2006


On 3/7/06, Bryan Sant <bryan.sant at gmail.com> wrote:
> > > vmstat
> > procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
> >  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
> >  0  0      0 585448  91132 907528    0    0     2     6   67    28  0  0 100  0
>
> Was this run while you were doing something with your client?  I don't
> think we're going to see anything useful unless there is a constant
> load while you run these commands.  This output show that exactly
> nothing is going on -- but that is correct if you aren't connecting
> with enough clients to actually see something in real-time.  What I
> was hoping to see is that the last column (wa -- "wait") would have
> something other than 0.  A value other than 0 would indicate that the
> CPU is waiting on I/O -- network or disk or something.

No, I wasn't doing anything with the client when I ran any of theses
commands, except for top, so you could see that it was barely doing
anything.  And therein is part of the problem, there doesn't appear to
be anything causing the delays, but there are very noticeable delays
when on linux.

> Again, we can't see anything measurable without some sustained client
> load while we look.  BTW - You're brave to run jboss as root :-).

I can't remember why we're running it as root.  It seems like there
were issues getting it to start up correctly, possible related to some
of the ports it listens on.

> Is it too late to rant about my feelings towards JBoss :-)?  Would you
> be willing to deploy your EAR to Geronimo just to get another data
> point on this?  If Geronimo is fast and JBoss is slow at least we can
> isolate it to a JBoss-on-Linux problem.

Go ahead, what's wrong with jboss?  I'm not averse to trying it on
Geronimo, but it probably won't actually happen, because of time
constraints, and people who have given up fighting MS, so they feel
that as long as it doesn't crash while people are using it we're
better off using windows.

> I have no idea why it's working well on W2K3 and not Linux with this
> data.  Can you add some logging to your app and timestamp your
> internal method calls to see how long JDBC queries are taking and
> other overhead.  Find out which calls are taking so long -- the
> hot-spots.

Yeah, that's what we want to do, but there are only two of us working
on this problem, we have lots to do, and I don't know much about this
section of the code, so it's probably going to be a few days before we
get to it. Since windows performs so much better, we're probably going
to end up putting windows on a different server to see if it was
crashing because of hardware problems (part of the long story of our
outsourced IT guy that screwed us over with a bunch of crappy
servers), until such time as we have to really dig into this.

> Also, add the following param to jboss' command-line
> -Dcom.sun.management.jmxremote -- you'll be able to connect to that
> JVM with a local instance of jconsole and watch threads, memory, and
> JMX instruments while the app runs.  Also, also, you can run "kill
> -QUIT <jboss pid>" while the app is running to have a stacktrace of
> exactly what's being executed at that moment dumped to stdout.  I'd
> like to see what's on your stack while one of your client requests is
> taking 5 seconds (though your timestamp logging will be more helpful
> than a raw stack anyway).
>
We'll have to try this.

Thanks for your help and advice.  Hopefully we'll get more time to
look into this.



More information about the PLUG mailing list