About Cache Capacity for a Service Instance

There are multiple parameters that affect the caching capacity of an Oracle Coherence data tier within an Oracle Java Cloud Service instance.

When you use Oracle Java Cloud Service to provision a service instance with a Coherence data grid cluster, you control the initial cache capacity with these configuration settings:

  • Compute Shape - The number of OCPUs and the amount of memory for each node in the Oracle WebLogic Server cluster. For example, the shape oc3 has 1 OCPU and 7.5 GB of memory. All nodes in the data grid cluster have the same compute shape.

  • Cluster Size - The number of Managed Servers in the data grid cluster. Each Managed Server is a Java Virtual Machine (JVM) running Coherence.

  • Managed Servers Per Node - The number of Managed Servers that run on each node in the data grid cluster. All nodes in the data grid cluster have the same number of Managed Servers.

When you create an Oracle Java Cloud Service—Coherence instance, the number of nodes that are provisioned for the data grid cluster is determined by the following formula:

Nodes = Cluster Size / Managed Servers Per Node

For example, if you set Cluster Size to 4 and Managed Servers Per Node to 2, Oracle Java Cloud Service will create 2 nodes, each running 2 servers. If the quotient is not a whole number, then it is rounded up to the nearest whole number. For example, if Cluster Size is 4 and Managed Servers Per Node is 3, your data grid cluster will consist of 2 nodes, each running 3 servers (a total of 6 servers).

Running multiple Coherence servers on each node can improve concurrency and memory management, but it generally also requires more processors and memory (larger shapes).


You cannot change these data tier configuration parameters (cluster size, compute shape, managed servers per node) after creating a service instance.

If you require maximum availability for the data in the data grid cluster, it must contain at least three nodes.

As your application workload increases and your Coherence data tier requires more capacity, you can use Oracle Java Cloud Service to scale out the data grid cluster. Each time you perform a scale-out operation, Oracle Java Cloud Service adds a single node to the data grid cluster. This node runs the same number of servers as the other existing nodes in the cluster. Similarly, a scale-in operation removes a single node from the data grid cluster. The application tier cluster and the data grid cluster in your service instance can be scaled independently of one another.

Consider the previous example in which a service instance’s Coherence data tier is configured with a Cluster Size of 4 and Managed Servers Per Node is set to 2. Scaling out a data grid with this configuration adds one node with 2 servers, as illustrated in this figure:

Each server on a Coherence node is a JVM process that is configured with a default heap size. The memory available for all Coherence servers on a node is 75% of the remaining memory after reserving 1.5 GB for the operating system. The available memory is then divided evenly amongst the servers on the node.

For example, consider a data tier whose compute shape has 7.5 GB of memory per node. The memory available for server heap is: 0.75 x (7 – 1.5) = 4.5 GB. If the data tier is configured for two servers per node, the heap size for each server is: 4.5 / 2 = 2.25 GB.

As a general rule for most Coherence applications, approximately one third (1/3) of a server’s heap is used for primary cache storage. The other two thirds of the heap is used for backup storage and scratch space. Therefore, if the total heap across all nodes in your data grid is 100 GB, the total cache size for your applications is approximately 33 GB. An exception to this rule is a data grid that’s comprised of a single node with a single server. In this scenario there is no high availability, and therefore backup storage does not consume any of the available heap.