How to rightsize virtual machines on Oracle Cloud

Why this matters

Oracle Cloud bills compute by shape, and flex shapes let you set OCPUs and memory independently. On x86, one OCPU maps to two vCPUs, so compare OCPU counts with vCPU counts only after converting. An instance that runs at low CPU but has memory set high pays for memory it does not use. The reverse also happens: teams keep a large fixed shape because one short batch needs the headroom.

Rightsizing is not only a bill exercise. It changes how an instance behaves under load. Too few OCPUs shows up as run queue, slow responses, and throttled background work. Too little memory shows up as swapping, OOM kills, or a database buffer cache that keeps shrinking.

Oracle Cloud makes the mechanics fairly direct. You can change OCPUs and memory on a flex shape, switch fixed shapes, and use instance pools with autoscaling. The work is deciding what to change, by how much, and when to stop.

Before you start

Collect at least two weeks of data, and include month end, batch windows, and peak login periods. The OCI Monitoring service keeps metrics for a limited window depending on resolution. Export or duplicate what you need before you change anything.

Enable the Oracle Cloud Agent Compute Instance Monitoring plugin on each instance if memory and disk metrics are missing. Hypervisor metrics such as CpuUtilization are available without the agent, but guest memory needs the agent. Check that the agent is running and the plugin is enabled in the instance details.

Tag instances with owner, environment, application, and cost center. Use Cost Analysis and budgets to group spend by compartment and tag. You need a clear owner for each resize because someone must approve the maintenance window and validate the application.

Agree on a maintenance window and rollback plan. A shape change can require a reboot. For stateful systems, confirm that the application tolerates a stop and start, or use a rolling change through an instance pool.

How to do it

Start with the instances that have the widest gap between provisioned capacity and observed use. Do not start with the largest bill line unless you also know its peak profile. A large instance with steady high use may be correct.

Work from a hypothesis. For example, a web tier with low CPU and stable memory may move down one flex step. A database with high memory and moderate CPU may need memory held while OCPUs drop. Write the hypothesis, the metric, and the rollback trigger before you touch the shape.

Use the same order for every instance: measure, test, change, watch. This keeps the change small and makes it easy to reverse.

1. Inventory instances and shapes. List every compute instance by compartment, shape, OCPU count, memory, and tag. Note fixed shapes that can move to flex shapes and flex shapes with memory far above CPU use.
2. Pull the right metrics. Use OCI Monitoring Metrics Explorer to chart CpuUtilization, MemoryUtilization, NetworkBytesIn and NetworkBytesOut, and disk throughput over a full business cycle. Compare peak and sustained values, not only the average.
3. Look for constraint signals. Check application logs, database wait events, swap use, and load average during peaks. Low average CPU with slow response during the busy hour means the shape is too small for that hour, not that it is oversized.
4. Test a smaller shape in a clone. Clone the instance or boot volume into a nonproduction compartment and apply the same shape change. Use a load test or replay real traffic to compare response time and error rate.
5. Change flex OCPUs or memory. In the instance details, choose Edit and adjust the flex shape OCPU and memory values. Schedule the reboot, confirm the new shape in the console, and watch the first peak.
6. Move fixed shapes to flex. If the instance uses a fixed shape, compare its CPU and memory profile with a flex shape in the same processor family. Change the shape during a maintenance window and keep the old boot volume until validation passes.
7. Set alarms and autoscaling. Create OCI Monitoring alarms for high CPU, memory, and latency, and use instance pool autoscaling for predictable load patterns. Set floors and ceilings so the pool cannot scale into a shape you have not tested.
8. Right-size in stages. Change one instance or one tier at a time, then wait for a full business cycle before the next change. Keep a short log of the old shape, new shape, reason, and result.

How to check it worked

After the change, compare the same metric over the same window. Look at peak CPU, memory headroom, swap, network throughput, and application latency. A smaller shape that runs at high CPU all day is not a saving if response time suffers.

Check the application logs for OOM kills, timeouts, and retries. For databases, check wait events and buffer cache hit ratios. For batch jobs, run the full job and compare elapsed time, not just the first hour.

Use Cost Analysis to confirm the shape change appears in usage. Billing data can lag, so set a reminder to review the next invoice. Also check that budgets and alerts still match the new spend pattern.

Keep the old shape and boot volume for a short period, then remove them. Record the change, the metric that justified it, and the date. That record is what makes the next resize faster.

Mistakes to avoid

Do not resize on average CPU alone. A virtual machine can look idle on average and still need its full shape during a short batch, a month end close, or a traffic spike. Use peak data and application latency together.

Do not shrink memory and CPU at the same time without a test. Memory pressure can hide behind a CPU change, and a database may need its cache even when OCPUs drop. Change one dimension, then measure.

Do not ignore the Oracle Cloud Agent. If MemoryUtilization is missing, you are guessing. Fix the agent and plugin first, then start the review.

Do not treat autoscaling as a substitute for a correct base shape. A pool with a floor that is too large pays for idle capacity. A ceiling that is too high can hide a bad shape choice. If you want an outside review, Cloudverg's Cloud cost audit package is one option, but fix the obvious shape mismatches first.

Frequently asked questions