[EMAIL PROTECTED] wrote:

> Hopefully, someone with more in-depth knowledge of JBoss (like Marc or 
> Rickard) can
> shed some light on some things we are seeing with JBoss and how it runs, 
> particularly
> on a Linux box.
> 
> 1)  When we start JBoss, there are a large number of java processes 
> started - I'm assuming
> that represents all the services, etc. that it needs.  Each one of these 
> processes is reported
> as taking 156M of memory!!  (More if we up the VM's heap size, etc.)
> 
>         a.  Why so much memory?  Is it because they are all running their 
> own VM??
>         b.  How come JBoss doesn't report the same number of processes or 
> memory on NT?
These aren't separate processes, they're threads. The linux thread 
implementation uses a slightly lighter weight process. If you do `ps 
-axf`, you'll see that they all have the same parent, which will be the 
java process that 'run.sh' kicked off.
The memory is a different issue. Running JBoss only, with about 10 beans 
deployed but no activity, 'top' shows all of these threads using 24MB. 
Since the threads share all their memory (that's the only thing that 
makes a linux pthread lighter-weight than a process), JBoss alone uses 
24MB (on my box, and this is a 2.1 build from CVS a few days ago)

> 
> 2)  Somewhere on the JBoss site I found a blurb on benchmarking (at least 
> I thought I did) that
> indicated it outperformed Weblogic.  Can someone outline the parameters of 
> that benchmark
> test?  Or at least point me to some numbers or info on previous benchmark 
> tests?
> 
> 3)  This is our real problem:  We start up a robot process that is logging 
> in only 15 users and
> it is bringing JBoss to it's knees (in fact it blows up!).  These 
> processes are testing a searching
> app that uses four JSP pages and four EJBs.  Not a whole lot to it, but we 
> do know that one of
> our beans doesn't utilize memory as good as it can (and it is being 
> rewritten as you read this).
> But there is NO WAY that 15 processes are going to take up 240+ Meg of 
> memory - as is being
> reported by the process monitor under Linux.
> 
> Three of the beans are Stateful Session, the fourth Stateless Session. All 
> are set to a min of 5
> and max of 25 for pooling.  Initially, the pool for the stateless bean 
> jumps up (because it is
> managing a connection to another box), but eventually they all stay around 
> the minimum.
The fact that these are around their minimum indicates that JBoss might 
not be the problem. How are the stateful beans used? Bear in mind that 
stateful beans inherently load the app server harder (the level of load 
your pushing right now really shouldn't be a problem, however)

> 
> We're thinking that maybe we'd get better results if we ran JBoss alone on 
> one box, then Tomcat
> or some other JSP/Servlet/Web container on another box to see if splitting 
> them apart gives us
> better performance.  Any ideas on that??
That might give you a better indication of where the problem is, if 
nothing else.

> 
> Using version 2.0 final. 
> 
> 
> TIA -
> 
> Robert
> 
> ps:  Weblogic didn't perform much better, to our relief.  Guess that means 
> that we could go
> back to the drawing board and inspect our code.
Yep! If you find anything generalizable, do let us know. No sense in 
everyone skinning there knees on the same rock.

> 
> 
> --
> --------------------------------------------------------------
> To subscribe:        [EMAIL PROTECTED]
> To unsubscribe:      [EMAIL PROTECTED]




--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]

Reply via email to