The following is the second of five posts which will list the best practices and performance suggestions for tuning one’s Oracle Coherence environment. This is a general guide that will evolve as new product features are added to Oracle Coherence.
The following is a general list of questions to review when troubleshooting performance issues with Coherence.
- What application server is being used in conjunction with Oracle Coherence?
- Is Oracle Coherence being run within the same JVM as the app-server container or is the data grid setup outside of the app-server container? (i.e. is storage disabled here with –Dtangosol.coherence.distributed.localstorage=false )
- How many storage nodes are being used for Oracle Coherence? (Is there adequate storage for all the data?)
- What size is the java heaps for these storage nodes?
- Are the out-of-the-box Oracle Coherence configuration files being used from within coherence.jar? (i.e. Coherence itself has not been tuned to the environment/application?) See Sample Cache Configuration Files for details.
- Are configuration files specified via a –D flag to the Oracle Coherence Cache Servers or within a jar file? i.e. -Dtangosol.coherence.override=<file> and -Dtangosol.coherence.cacheconfig=<file> being used?
- What is the Thread-count set for Oracle Coherence?
- What type of partitioning is being used? Is a near-cache being used or replicated? “Partitioned/Distributed cache gives a real linear scalability and should be used in pretty much all scenarios. With Replicated cache the same data are copied over to all the nodes and is very performance taxing if data are changed.” Information on the near-cache, partitioned cache and replicated cache.
- Multicast or Unicast? (Review the Multicast Troubleshooting section below.)
- Is this a 32 bit JVM or a 64 bit JVM? JRockit or Sun JVM?
- What garbage collection algorithm is being used?
- Review the Platform-Specific Deployment Considerations section of the documentation.
No comments:
Post a Comment