nbkd72e
asked on
One Large JVM vs. Multiple Smaller JVMs
Based on the latest JVM technology (J2SE 5 or higher), hardware and Application Server implementations (e.g. WebLogic 9.x or WebSphere 6.x), which of the following two configurations is better on a multiple-CPU UNIX machine:
1. One large JVM with 2-4 GB heap size and 200+ threads for a single Application Server instance.
2. Two or more smaller JVMs, each with < 1 GB heap size and < 100 threads for an Application Server cluster of multiple application server instances
What are the major pros and cons of each solution?
1. One large JVM with 2-4 GB heap size and 200+ threads for a single Application Server instance.
2. Two or more smaller JVMs, each with < 1 GB heap size and < 100 threads for an Application Server cluster of multiple application server instances
What are the major pros and cons of each solution?
> when you increase the heap, the max no. of threads get decreased!
can you pls explain little more? i thought the max no of *active* theads depends on no of CPUs of the box.
can you pls explain little more? i thought the max no of *active* theads depends on no of CPUs of the box.
>>can you pls explain little more?
for e.g.,
heap #of threads allowed
-Xmx128m 7500
-Xmx1024m 2500
for e.g.,
heap #of threads allowed
-Xmx128m 7500
-Xmx1024m 2500
>>i thought the max no of *active* theads depends on no of CPUs of the box.
though I have not tested this, I don't think so!
though I have not tested this, I don't think so!
GC works better on larger heap JVMs than smaller ones. The GC tuning option "-XX:+UseParallelGC" highly depends on the no of CPU available on the box. It would run efficiently if only one JVM is running.
Have a look to various GC options:
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
Have a look to various GC options:
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I really want to hear from people who has done load test and application server performance tuning against those two scenarios, especially the experiences of tuning a high-profile production system.
ASKER
I was told by some application server vendor consultants a few years back that the second approach would perform better. But I am not sure if that principal is still valid based on the latest JVM, hardware and App Server technologies.
I think it worth to specify my concerns of the single large JVM approach (the first one):
1) GC - How efficiently the JVM can handle 2-4 GB heap size without causing performance penalties. Do you think having multiple JVMs each handles GC more a smaller heap will be more efficient?
2) Managing threads - 1000 threads per Java process vs. 200-300 threads per Java process (with 4 Java processes on the same machine), would the second case managing Java threads more efficiently, including thread scheduling, handling Java synchronization (or managing the locks/mutexes/monitors) ?
3) As somebody already mentioned, the availability and reliability. Having to deal with something extremely large always challenges the underneath technology or implementation, and potentially need more time to get mature.
I think it worth to specify my concerns of the single large JVM approach (the first one):
1) GC - How efficiently the JVM can handle 2-4 GB heap size without causing performance penalties. Do you think having multiple JVMs each handles GC more a smaller heap will be more efficient?
2) Managing threads - 1000 threads per Java process vs. 200-300 threads per Java process (with 4 Java processes on the same machine), would the second case managing Java threads more efficiently, including thread scheduling, handling Java synchronization (or managing the locks/mutexes/monitors) ?
3) As somebody already mentioned, the availability and reliability. Having to deal with something extremely large always challenges the underneath technology or implementation, and potentially need more time to get mature.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ksivananth,
I agree we don't design system for GC, but we definitely design system for better performance, and then tune with GC for low pause timings.
I agree we don't design system for GC, but we definitely design system for better performance, and then tune with GC for low pause timings.
> With single node approach, the two is not possible.
1 or 2 - its single point of failure.
> Even if you vconfigure single node with high config 2GB... what will you do if the app recieves more load than this config?
You really need very very powerful box or your server is doing nothing (kind of ping server)
1 or 2 - its single point of failure.
> Even if you vconfigure single node with high config 2GB... what will you do if the app recieves more load than this config?
You really need very very powerful box or your server is doing nothing (kind of ping server)
I have read some ehere that 1GB is good trade off!
More instances can share the load and the possibility of crash is less and possible to have failover mech.