Three different things
| Set by | Example | Fix | |
|---|---|---|---|
| Service limit | Oracle, per tenancy (region/AD) | E5 cores per AD, LB count, ADB ECPUs | Request a limit increase |
| Compartment quota | Your administrators | Dev compartment may use 64 E5 cores | Change the quota policy |
| Capacity | Physical availability | "Out of host capacity" for a shape in an AD | Other shapes/ADs, capacity reservations |
LimitExceeded, QuotaExceeded and "Out of host capacity" errors map to these three (see the launch failures post).
1. Check limits and availability
oci limits value list --compartment-id $TENANCY --service-name compute --all \
--query 'data[?contains(name, `e5`)].{name:name, scope:"scope-type", ad:"availability-domain", value:value}' --output table
oci limits resource-availability get --compartment-id $TENANCY --service-name compute \
--limit-name standard-e5-core-count --availability-domain "$AD"
resource-availability shows used and available counts. Use it in pre-launch checks and pipelines.
2. Compartment quotas for fair sharing
# quota policy statements
set compute-core quota standard-e5-core-count to 64 in compartment dev
set compute-core quota gpu-a10-count to 0 in compartment dev
zero database quotas in compartment sandbox
set database quota adb-ecpu-count to 8 in compartment sandbox
- Stop sandboxes and dev from consuming capacity production needs.
- Block expensive resources (GPUs, Exadata) where they aren't approved.
- Quotas apply down the compartment tree. Plan them with your compartment design.
3. Request increases ahead of need
- Before migrations, launches and seasonal peaks: list required limits per region/AD, add headroom, request increases.
- Include the DR region. New regions start at default limits.
- Large GPU or bare metal requests can take time. Request early with a justification.
4. Capacity reservations
Compute capacity reservations hold capacity for specific shapes in an AD/fault domain, billed (at a reduced rate for unused reserved capacity, check current terms) whether used or not:
oci compute capacity-reservation create --compartment-id $C --availability-domain "$AD" \
--display-name dr-app-tier --instance-reservation-configs \
'[{"instanceShape": "VM.Standard.E5.Flex", "instanceShapeConfig": {"ocpus": 4, "memoryInGBs": 32}, "reservedCount": 6}]'
Use them for Tier 1 DR targets, critical scale events and scarce shapes. Launch instances into the reservation by specifying it at launch.
5. Design to reduce limit pressure
| Pressure | Response |
|---|---|
| Single shape family in one AD | Allow alternative shapes (E5/E4, A1) and multiple ADs/FDs |
| Many small load balancers | Consolidate with hostnames; NLB for L4 |
| One tenancy-wide pool for everything | Compartment quotas per environment |
| Bursty batch | Preemptible capacity and queue-based scaling |
6. Make it a gate
Design reviews and go-live checklists include: limits listed and checked in primary and DR, quotas set for the new compartments, capacity strategy for scarce shapes, evidence attached (CLI output, request IDs).
Warning
Limit increases don't create capacity. If a shape is out of host capacity in an AD, a higher limit won't help. Plan alternative shapes, other ADs/fault domains, or reservations.
Checklist
- Limits, quotas and capacity distinguished in the design
- Limits and availability checked for primary and DR
- Compartment quotas protect production and block unapproved resources
- Increases requested ahead of events
- Capacity reservations for critical/scarce needs
- Gate in design and go-live reviews