The efficiency scores of your CPU and memory resource use translate technical optimization into business value. Efficiency scores put a monetary value on savings and waste.

Efficiency is calculated as the percentage of usage over the request, which is why efficiency scores can exceed 100% if the usage is higher than the requested resources. Wasted cost is derived from the total cost minus the cost of the used capacity, but this figure currently includes intentionally unallocated capacity for future growth and disaster recovery.

To reduce spending, it is necessary to optimize resource allocation by reducing memory requests or adjusting CPU limits, or both. However, technical details of optimization, such as changes in megabytes of memory are often misunderstood. Metrics such as being 66% cost efficient or wasting $20,000 in a cluster are more tangible. These figures make it possible for financial departments to justify reallocating money by identifying the largest resource offenders and assigning development teams recommendations to act upon.

However, it is important to interpret efficiency scores within the context of your organization’s availability strategy. A seemingly low efficiency score, for example 51% CPU efficient, might be appropriate depending on the number of availability zones (AZs) deployed. If you have two AZs, a 50% cluster utilization (or 51% efficiency) is ideal to absorb the capacity of a failing cluster, but if you have three AZs, you need a 66% utilization rate. In addition, high efficiency is great for optimizing utilization but it leaves little room for cluster growth.

On the other hand, efficiency scores exceeding 100% can indicate a failure risk, especially with memory usage. In this case, more resources are being used than are available or guaranteed by requests. For memory, using more than 100% of the guaranteed request can cause the scheduler to crash the application entirely, making scores greater than 100% efficiency risky, particularly if all applications are operating above 100% efficiency. You must understand your environment, including the kind of resource being over-allocated and the available room for other workloads to understand the meaning of efficiency score.

OpenShift permits applications to use more resources than they request by defining a request (the guaranteed resource amount) and a limit (the maximum amount allowed). While CPU usage beyond the request can be throttled when reaching the limit (application running slower), memory usage beyond the request can cause the scheduler to kill the application, depending on node resources available. A common industry recommendation to mitigate memory risk is to set the memory limit equal to the memory request.