How Uber, OCI™, and Ampere® Co-Optimized OCI AmpereOne® M A4 Compute

Summary

Uber, Oracle Cloud Infrastructure, and Ampere co-optimized the OCI AmpereOne M A4 instance family after migrating large workloads from on-premises data centers to Arm-based cloud infrastructure. Early A1 and A2 deployments exposed dual-socket latency, Go performance degradation associated with smaller TLB and cache sizes, and insufficient single-thread performance for Gurobi services. Uber shared workload characteristics and targets that informed AmpereOne M silicon and an OCI FlexSKU, while the teams evaluated frequencies, core counts, deployment models, memory ratios, and storage. For latency-sensitive stateless services, the resulting guidance favors higher-frequency CPUs, about 8 GB per vCore, and virtual machines; throughput-oriented storage systems use parallelism, flexible memory-to-core ratios, and local NVMe or remote block storage according to locality. The collaboration is presented as improving price-performance and supporting energy-efficient, cost-optimized multi-architecture computing at scale.

Takeaways

1. 1

   Dual-socket systems reduced performance for latency-sensitive operations because of cross-socket link bandwidth; Ampere’s high core counts per socket removed the need for multi-socket servers.

2. 2

   Uber associated Go performance degradation and GOMEMLIMIT-related out-of-memory errors mainly with smaller TLB and cache sizes, which caused more page faults and slower garbage collection.

3. 3

   A4 workload guidance separates latency-sensitive stateless services from throughput-oriented storage systems, matching higher frequency and predictable memory behavior to the former and flexible parallel storage configurations to the latter.