InfoQ

Uber Moves Beyond CPU Cores with Performance-Aware Scheduling for Stateful Workloads

8.5内容质量
Uber Moves Beyond CPU Cores with Performance-Aware Scheduling for Stateful Workloads

TL;DR · AI 摘要

Uber通过归一化计算单元（NCUs）解决有状态工作负载的CPU分配问题，提升资源利用率。

核心要点

  • 不同CPU核心性能差异可达2倍，传统分配方式导致资源浪费或不足
  • Uber的NCUs通过性能因子（100-190）实现跨硬件的计算能力标准化
  • 生产数据动态更新性能因子，ARM与x86系统性能差异达数倍

结构提纲

按章节快速跳转。

  1. §引言

    Uber发现传统CPU核心分配方式在异构服务器集群中存在资源浪费和可靠性问题。

  2. ·性能差异挑战

    单线程性能差异达2倍，导致相同工作负载在不同硬件上需不同核心数。

  3. ›NCUs解决方案

    通过性能因子标准化计算能力，将物理核心需求动态转换为归一化单位。

  4. ·性能因子机制

    基于硬件基准（100）和生产数据动态调整，新型服务器可达190性能因子。

  5. ›技术实现

    Odin平台根据服务器类型分配性能因子，自动转换CPU需求为物理核心数。

  6. ·实践验证

    Kafka在ARM与x86系统间性能差异显著，需持续用生产数据更新性能因子。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • Uber的性能感知调度
    • 问题背景
      • CPU性能差异达2倍
    • 解决方案
      • NCUs机制
      • 性能因子（100-190）
    • 技术实现
      • Odin平台
      • 生产数据动态更新

金句 / Highlights

值得收藏与分享的关键句。

#DevOps#资源调度#Uber#性能优化
打开原文

Uber 超越 CPU 核心：面向有状态工作负载的性能感知调度 - InfoQ

InfoQ 首页 News Uber 超越 CPU 核心：面向有状态工作负载的性能感知调度

DevOps

扩展 OpenTelemetry：管理收集器、配置和成本（11月19日网络研讨会）

Uber 超越 CPU 核心：面向有状态工作负载的性能感知调度

Oct 27, 2026 3 分钟阅读

作者：

#### 关注我们

Youtube

232K 粉丝

Linkedin

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 点赞

Bluesky

收听本文 -

0:00

音频准备就绪

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

  • 阅读列表

Uber 推出了标准化计算单元（NCUs），以在高度异构的服务器舰队中实现更一致的 CPU 分配。该方法在 Uber 的 Odin 有状态编排平台中实现，考虑了处理器性能的差异，而不是将每个 CPU 核心视为等价。

Odin 管理着约 500 万个 CPU 核心，涵盖本地数据中心和公共云，包括多代 x86 硬件和 ARM 处理器。Uber 发现，最快和最慢核心之间的单线程性能差异可能高达两倍。因此，相同的工作负载根据运行位置可能需要显著不同数量的物理 CPU 核心。

这个问题带来了两种相互竞争的风险。根据最慢硬件分配资源可能在更快的机器上浪费容量，而根据平均使用率分配资源则在工作负载转移到较慢服务器时可能导致资源配置不足。对于有状态工作负载，由于通常无法将流量转移到其他机器，后者可能演变为可靠性问题。

Uber 的解决方案是将工作负载所需的计算性能与提供该性能的物理核心数量分离开来。

Odin 为每种服务器类型分配一个性能系数，以较旧服务器一代为基准（100）。新硬件的系数可能显著更高；Uber 报告某些服务器的系数接近 190。这些系数最初在硬件认证期间确定，随后通过生产工作负载数据进一步优化。

通过这些系数将 CPU 使用情况转换为标准化单位。Odin 随后可以确定工作负载需要特定数量的计算容量，并根据承载它的服务器将其需求转换为不同数量的物理核心。

因此，在更快的硬件上运行的工作负载可能获得更少的核心，而相同工作负载在较慢硬件上运行时会获得更多的核心。目标不是使核心数量相同，而是使计算能力更加可比。

Uber 还发现不同技术之间的性能系数存在差异。例如，其对 Kafka 的测量显示，ARM、旧版本地硬件和新版 x86 系统之间的性能差异显著。因此，公司使用生产测量数据更新系数，而不是完全依赖合成基准测试。

对于无状态服务，服务器之间的差异通常可以通过负载均衡解决。流量可以导向负载较轻或更快的机器。

有状态系统不具备相同的灵活性。某个请求可能需要到达包含特定分片或数据片段的服务器。将请求转移到其他地方并不能解决底层资源问题。

在该文章中，Uber描述了某些工作负载，在这些负载中，领导者消耗的CPU资源是其追随者的十倍以上。如果该领导者从高性能服务器迁移到低性能服务器，其CPU消耗可能会显著增加，即使工作负载本身没有变化，也可能导致资源压力。

Uber已将该方法扩展到约140万个自动扩展的Odin工作负载的CPU核心上。对于Kafka，初始时不同服务器类型之间的CPU利用率差异约为8个百分点，最热的硬件利用率比最冷的硬件高出约50%。

引入性能感知分配后，差异缩小到约3个百分点，最热的硬件利用率仅比最慢的硬件高出约10%。Uber还减少了约8%的Kafka CPU分配，其中大部分减少发生在性能更高的硬件上，这些硬件的节省潜力可能更大。

该方法与Kubernetes使用的CPU抽象有所不同，Kubernetes中CPU请求以核心或毫核表示。Kubernetes有意将CPU单元视为绝对的CPU时间量，而不管底层机器的规模。这种抽象对于可移植的工作负载定义效果良好，但本身并未明确表达不同处理器世代之间的相对性能。

Uber的NCU模型解决的是一个略有不同的问题：使资源本身具备性能感知能力。与其主要决定一台机器上应容纳多少工作负载或工作负载应获得多少CPU资源，它更关注CPU分配实际代表多少计算能力。

main wrapper for authors section

关于作者

section title

main wrapper for each author

#### Craig Risi

显示更多

显示更少

#### 本内容属于DevOps主题

##### 相关主题：

  • DevOps
  • 人工智能、机器学习与数据工程
  • 状态机
  • 云
  • Apache Kafka
  • 云中的自动化与大规模管理
  • Kubernetes
  • Uber
  • AWS
  • 相关编辑
  • 相关赞助商 AI的物理限制：AI如何重构数据中心
  • 相关赞助商 PostgreSQL面向时间序列规模构建 处理海量时间序列数据时，使用PostgreSQL无需牺牲性能。了解Tiger Data如何实现高速数据摄入、快速查询和可扩展存储。了解更多。

InfoQ新闻通讯

每周五汇总InfoQ最新内容，每周二发送。加入超过25万名高级开发者的社区。查看示例

我们保护您的隐私。 /think