Summary: Instructions and best practices for tuning large-scale deployments.
Large Cluster ConsiderationsWhen designing a large cluster, there are several things that need to be taken into account to assure that the cluster will be able to handle heavy loads, and perform quickly and stably. When speaking of a larger cluster, we are referring to more than few hundreds. If this is the size of cluster you intend to build, the following considerations are relevant for you. Unregistering Spaces "Disappear" from LUSThis occurs when a large amount of memory is consumed in the process, causing extensive JVM GC spikes. This results in high CPU usage and distracts the LeaseRenewManager (a long GC/CPU clock causes the LeaseRenewManager to miss the default 4 seconds, or to attempt to renew the lease, firing a space service un-registering event). If the LUS fires an event to unregister a space, the UI spaces tree node represents it using a specific icon. Additionally, specific logging is printed out in the UI. To avoid the unregistering of spaces, add resources (memory, CPU) or spaces, or tune the LeaseRenewal maxLeaseDuration and roundTripTime. These two values can be configured using the config\services\advanced-space.config file (can be found inside JSpaces.jar): //Default value for net.jini.lease.LeaseRenewalManager.roundTripTime default value 4 seconds roundTripTime=4000; //Default value for net.jini.lookup.JoinManager.maxLeaseDuration default value 8 seconds. maxLeaseDuration=8000;
Minimize RMIRegistry OverheadSince every space container starts an embedded RMIRegistry service, it creates a set of threads which consume a large amount of resources.
Service Grid CPU, Memory, Disk CPU Measurement Overhead
For more details, see the following services.config file elements: com.gigaspaces.management.system.memory com.gigaspaces.management.system.cpu com.gigaspaces.management.system.disk Setting Redundant total_members for Clusters
Lookup and Mahalo Service Settings
Setting List of JARs Accessible through rmi.server.codebase or HTTPDWhen adding a very long list of files (or very large files in size), all clients attempt to download these files over the wire. This causes dozens of MBs go over the wires repeatedly per each type of client, exhausting the HTTPD and the network.
This Example of a Service Grid Deployment Descriptor contains a long list of files. See also the 50MB weblogic.jar. Cluster Availability MonitoringWhen a large cluster is monitored for availability, it is recommended to increase the value of the Monitor thread to a maximum. Usually, when there is no failover or when there are no backup-only spaces, the Monitor thread can be safely set to its maximum value; since clients directly interact with the space members. If either is detected as unavailable, the Detector thread is responsible for detecting their re-availability.
Many Clients Accessing SpaceWhen attempting to run hundreds of clients, which need to find a space and perform operations; a few considerations need to be taken. Calling SpaceFinder
Cluster Availability MonitoringWhen there are many clients monitoring the availability of a cluster, it is recommended to increase the value of the Monitor thread to a maximum. Usually, when there is no failover or there are no backup-only spaces, the Monitor thread can be safely set to its maximum value; since clients directly interact with the space members. If either is detected as unavailable, the Detector thread is responsible for detecting their re-availability.
|
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |