The jBoss documentation is simply wrong and grossly outdated in any
meaningful way. See my extensive post on a related issue a few days ago:
http://www.mail-archive.com/jboss-user%40lists.sourceforge.net/msg07518.html
Linux, as of the 2.2 kernel and 1.3 Sun JVM, certainly does have real
native thread support, and this is the default installation. See:
http://developer.java.sun.com/developer/technicalArticles/Programming/linux/
Basically, the choice between "native" threads and "green" threads is
an issue of whether the threads are to be scheduled by the system kernel
scheduler or by the JVM internal scheduler. If the system scheduler is
used, the switching takes place in kernel mode and more efficient use of
resources can be made; in particular, an SMP machine can have multiple JVM
threads running simultaneously on different processors. If the JVM
internal scheduler is used, the switching takes place in user mode which
is going to be somewhat slower, and all of the threads within the JVM will
be limited to a single processor on an SMP machine.
There is a trade-off here: for nearly all practical Java applications,
running with native threads is going to result in better performance, even
for a uniprocessor machine. The exception is a Java application which
needs to create a huge number of threads, maybe into the several hundreds,
in which case green threads might be a realistic option. Note that any
application which has hundreds of threads is going to thrash the scheduler
regardless of whether that scheduler is inside the JVM or the kernel, and
serious consideration should be given to rearchitecture.
There is some sort of nasty myth that Linux threads are somehow less
"thready" than Windows threads because they show up in the process table.
This is an implementation choice that has negligible effect on performance
(after a thread has been initially created) because threads share task
descriptors which, on most hardware (including Intel), have physical
meaning in the CPU. In other words, the Linux kernel switches between
threads as quickly and with essentially the same amount of overhead as a
thread switch on Windows, although Linux does take some penalty in initial
thread creation. This is again a trade-off, because the Linux thread
model allows a single-tier scheduling algorithm while Windows requires a
double-tier scheduling algorithm. What green threads on Linux do is
closer to the Windows scheduling model, although on Windows the thread
scheduler runs in kernel mode and is therefore faster than the user-mode
JVM internal scheduler on Linux that is only used with green threads.
The reason Linux will impose limitations on jBoss capacity that are not
present in Windows is because the Linux kernel is designed with the
assumption that any process spawning hundreds of threads has lost its mind
and should be stopped for the good of the system. If one chooses to do
so, one can -- as I explain in my earlier post referenced above --
recompile the Linux kernel to raise the task count limit up into the
stratosphere; a little more than 4000 tasks can be allowed systemwide on
Intel hardware. (This has a physical hardware basis: there are 8192
descriptor slots on Intel hardware, and each Linux task needs two, so the
dead maximum capacity on Intel hardware is 4096. In turn, no single user
is allowed more than half the systemwide supply of task slots, so when
jBoss hits 2048 the kernel will deny it the ability to start new threads.
Note that this is a factor of 8 greater than the kernel default.) With
the kernel recompiled to allow more tasks, Linux will have essentially the
same capacity in terms of thread count as Windows, with the difference
that Linux will continue running if a non-root application requests every
available thread while Windows in that situation will crash.
In summary:
1. Linux has native thread support as of the 2.2 kernel and 1.3 Sun JVM,
2. SMP, if available, is fully utilized with native thread support,
3. There are reasons why one might choose not to use native thread support
on Linux and use green threads instead,
4. The capacity of Linux in terms of thread count can be boosted to a
level equivalent to that of Windows by changing a number in the kernel
source and recompiling, and
5. It is undesirable to have very large numbers of threads because then
the system will spend an increasingly larger portion of time in thread
switching and scheduling overhead at the expense of useful work.
-- Mike
On 2001-06-24 at 14:08 +0800, Fei Wang wrote:
> I have found the following at
> http://www.jboss.org/documentation/HTML/ch10s02.html.
>
> Linux users probably already know that linux does not support real
> threads. Under heavy load, JBoss will for example crash with 200
> concurrent users under linux, whereas it can handle 1000 of them on
> the same box with Windows 2000. Of course, if you use Apache or Jetty
> in front of JBoss to handle the thread pooling, this will not be a
> problem.
>
> So if it is ture, I think that Apache should be a reasonable front
> part, especially for production use.
>
> Fei Wang
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
