:)))))
sebastien is running the load tests on a old friend's SPARC in France and
the 1.3 vm has thread pooling and maps to real threads (unlike linux) and
all and he says the stuff just flies, mucho stable and great memory heap
usage thanks to the pooling...
he! I am still very proud of being a SUN graduate :)
marc
|-----Original Message-----
|From: marc fleury [mailto:[EMAIL PROTECTED]]
|Sent: Friday, October 20, 2000 12:51 PM
|To: jBoss Developer
|Cc: jBoss
|Subject: RE: [jBoss-Dev] Windows >> Linux???
|
|
||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.
||
||
||
||
