|The 30x load just means that 30 processes are ready to run. You'd
|need to look at another stat to find out what percentage of the
|CPU is in use. top will tell you. The load average is interesting,
|but it's pretty system specific. A load average of 30 on a single
|processor machine is probably pretty serious, but on a 32 processor
|system it would mean that at least one processor was idle. I've
|worked on a 8 processor Alpha with load averages at 170 or so, and
|emacs ran just fine :-).
:), which is significant :0)
|Linux is different from almost every other OS in the way it handles
|threading. Linux doesn't really draw a clear distinction between
|threads and processes - they're treated the same for scheduling
|purposes, the only difference between a thread and process is how much
|of their parents memory they can see.
oh so when top shows 15% mem for *each* thread it means that the jvm uses
15% mem that's all.
|In the default configuration of most Linux kernels, there is a maximum
|of 512 processes and/or threads, which is a compiled-in limit (at
|least up through 2.2 - I haven't checked 2.4). A normal user by
|default can only create a maximum of 256 processes/threads, so your
|load test is doomed to failure on most Linux systems, at least with a
|JVM which uses native threads. A green threads JVM would most likely
|survive it, though, although then you lose scalability on SMP systems.
yes we will test 2.4 (compiled for our machine specifically, beast, we will
see)
|Typically, in a case like this, the answer is thread pools. You would
yes, that is the obvious one. Also I keep coming back to "jboss will live
under apache/resin/whatever" and so the real thread pool is done by apache.
In case you use them you are all safe, since the thread management is not
RMI. The other thing we have been thinking of is decoupling the Invocation
layer (RMI, SOAP) threads from the invocation stacks by way of a queue (JMS)
which we could then set to have 10 working threads. That is a pretty
trivial solution, but for now I think the embedded thing is what we will see
mostly. IN clear the configurations with JMX are flexible enough that we
could disable the queue for an embedded configuration in a j2ee stack and
enable them for a standalone configuration.... still more work from us that
NT doesn't require
"losing my religion"
marc
|create enough worker threads to keep each processor in the system busy,
|and then let the client requests be handled by a thread in the pool.
|The rule of thumb is to create a thread per CPU, plus a thread for each
|thread you expect to be blocked on I/O, plus one or two more just be
|sure. It's definitely easier said than done, but it's definitely
|preferable to running the system out of threads.
|
|It works pretty well on Windows, too.
|
|
|
|
