Program on high-performance hardware deployment strategy:
4 is a hardware system CPU, 16GB of physical memory, the operating system is a 64-bit CentOS, Resin as a web server. Administrators can choose the 64-bit JDK1.5, and the parameters -Xmx and -Xms of the Java heap fixed at 12GB.
High-performance deployment on hardware, mainly in two ways :
1. large memory used by the 64-bit JDK
2. Using a number of 32-bit virtual machine cluster to create a logical use of hardware resources
For user interaction is strong, sensitive to the dwell time of the system can allocate large heap premise to the Java virtual machine is a safe application of Full GC control frequency low enough, at least to a low not affect users, such as a dozen hours or even a day to appear once a Full GC, so you can keep the memory space available to a stable level through the implementation of regular tasks in the middle of the night even trigger Full GC server automatically restart
Full GC frequency control key is to look at the vast majority of applications in line with the principle of whether the objects Chaosheng evening off, that the survival time for most objects should not be too long, especially large quantities of objects can not be successful, generating long survival time , so as to safeguard the stability of the old space years
If you plan to use the 64-bit JDK to manage large memory, also we need to consider the following issues may face:
1. memory recall cause long pause
2. At this stage, 64-bit JDK performance test results are generally lower than 32 JDK
3. The need to ensure adequate stability program, since this application if the heap overflow generated almost can not generate a heap dump snapshot, even if it is almost impossible to produce a snapshot of the analysis
4. In the same 64-bit program memory consumption JDK generally greater than 32 JDK, which is due to expansion of the pointer, and the data type of alignment caused by such factors Filler
If you use the second approach, using multiple 32-bit virtual machine cluster to create a logical use of hardware resources. The specific approach is to start on a physical machine a plurality of application server processes, each server process assign a different port, then set up in a front end load balancer to assign manner reverse proxy access requests.
The second way to use logical cluster deployment, you may experience the following problems:
1. Try to avoid competitive global node resources, the most typical is the disk competition, each node if simultaneous access to a disk file, then easily lead to abnormal IO
2. The most effective is difficult to receive some resource pools, such as connection pools are generally establish their own independent connection pool in each node, this can lead to some nodes pond full while others still have more spare nodes. Although you can use a centralized JNDI, but this has a certain complexity and may bring additional performance overhead
3. Each node is still inevitably be a 32-bit memory limitations, only in 32-bit Windows platforms 2GB of memory per process, taking into account the memory overhead than the heap that is generally open to a maximum of 1.5GB. In some Linux or Uninx system, you can upgrade to 3GB and even closer to 4GB of RAM, but 32 are still limited by the maximum memory 4G
4. extensive use of local caching application logic in the cluster can cause greater waste of memory, because on each logical node has a cache, which can be considered when the local cache instead of centralized cache
Back to the above case, the final deployment scenarios adjusted to build five 32-bit JDK logic clusters, each process is calculated by 2GB of memory (heap is fixed at 1.5), taking up 10GB of memory. In addition the establishment of a balanced front-end Apache service as a proxy to access the portal. Taking into account the user is more concerned about speed of response, and the main pressure document services focused on the disk and memory access, less sensitive CPU resources, so instead CMS collector garbage collection.