Sizing Oracle Coherence Applications

The following is the last of the 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.

Sizing Oracle Coherence

Remember there are 4 types of virtual machines in Coherence:

1. JVMs that are used for data storage (“storage JVMs”)
2. JVMs that run client applications and do not store data (“client JVMs”)
3. JVMs that run client applications and connect to the cluster via Coherence*Extend (TCP/IP)
4. .NET applications that run client applications and connect to the cluster via Coherence*Extend (TCP/IP)

The protocol for storage and client JVMs (type 1 and 2 above) is TCMP (“Tangosol Cluster Management Protocol”, based on UDP unicast).

 

Tips for Sizing Oracle Coherence

• Allow extra space for overhead

• Every object has one full backup on another JVM on another machine

• If a JVM fails, Oracle Coherence automatically fails over AND creates new backups on other JVMs

• This means that if a JVM fails, other JVMs will need to accommodate the backups of the objects

• Rule-of-thumb: each 1 GB JVM can store 350 MB of actual object data

• That means a 16 GB machine will support about 4.5 GB of raw object data. 13 JVMs * 350 MB = 4.55 GB

Question #1:    How many 1 GB JVMs can you run on a box with 16 GB of RAM?

Answer: At most 13
Start with 16 GB of RAM
Subtract RAM required for OS and other apps
/ divide by 1.2 (remember, 1 GB of heap uses 1.2 GB of RAM)
(16 GB – 400 MB ) / 1.2 GB = ~ 13

Question #2:    How many 16 GB machines will be required to support 20 GB of data in the grid?

Answer: At least five (six for HA)
* Each JVM handles 350 MB
* You have 13 JVMs per machine
* You have 4.5 GB per machine (13 * 350 MB)
* 20 GB / 4.5 GB per box = 4.44
* Round up to 5

I hope these series of five posts on Oracle Coherence have been helpful to you!