写点什么

CPU 隔离:管理和权衡

  • 2022-04-06
  • 本文字数:1784 字

    阅读完需:约 6 分钟

CPU 隔离:管理和权衡

SUSE Labs 团队探索了 Kernel CPU 隔离及其核心组件之一:Full Dynticks(或 Nohz Full),并撰写了本系列文章:

 

1. CPU 隔离 – 简介

2. CPU 隔离 – Full Dynticks 深探

3. CPU 隔离 – Nohz_full

4. CPU 隔离 – 管理和权衡

5. CPU 隔离 – 实践

 

本文是第四篇。

 

CPU 隔离和 nohz_full 用户需要了解的基本原则:干扰很少能被消除,而是转移到其他地方。

管理


我们之前曾简要解释过,内务管理是内核需要做的周期性工作或事件驱动的基础工作,目的是维护其内部状态和服务,例如更新调度程序的内部统计数据或计时。

 

在正常的配置下,每个 CPU 都要承担内务管理工作。相反,nohz_full 配置会以隐含方式移除 nohz_full 集合之外的所有的内务管理工作。

 

也就是说,如果您有 8 个 CPU,并隔离 CPU 1、2、3、4、5、6、7:

 

nohz_full=1-7


则 CPU 0 将单独处理内务管理工作。这些工作涉及:

 

  • 未绑定计时器回调执行

  • 未绑定工作队列执行

  • 未绑定 kthreads 执行

  • 计时更新(jiffies 和 gettimeofday())

  • RCU 缓冲期跟踪

  • 代替隔离的 CPU 进行 RCU 回调执行

  • 代替隔离的 CPU 执行 1Hz 残余的已卸载计时器 Tick

  • 根据您的扩展设置:

  • 可以绑定的硬件 IRQ

  • 除隔离的工作负载以外的用户任务


尽管这些项目通常可由一个 CPU 代替其他 7 个 CPU 处理,但这种布局并不趋于无穷尽。随着 CPU 数量的增加,同时,随着内存和缓存的进一步分区,内务管理任务可能需要共担。通常情况下,为每个 NUMA 节点配置一个管理 CPU 是一种不错的方法。如以下配置所示:



由于 CPU 0 - 7 属于节点 0,CPU 8 - 15 属于节点 1,默认设置如下所示:

nohz_full=1-7,9-15


在测试阶段,建议通过 top/htop 等工具检查和监控管理程序的活动,以确保它们没有超负荷。例如,如果以上设置显示 CPU 0 或 CPU 8 的负荷为 100%,则可能需要添加更多的管理 CPU,尽管这种情况更有可能使用更多的节点来处理。

 

同样需要注意的是,对内核的访问(例如系统调用或内存故障)可能会产生更多的内务管理活动,并导致 CPU 承担更多负载。通常不建议从隔离的 CPU 中请求内核服务,这一点我们将在下一章介绍。

 

在任何情况下,内核都有内务工作需要处理,这不能忽略。如果所有 CPU 都被传递到“nohz_full=” 内核参数,则 CPU 0 将从隔离集合内随意清理出来,并为其单独分配内务管理工作,使用的消息如下:

NO_HZ: Clearing 0 from nohz_full range for timekeeping

 

因此,要注意的是:被隔离的 CPU 之所以获得无抖动的特性,是因为其他 CPU 承担了更多工作,而至少一个 CPU 需要为这些工作做出牺牲。

 

然而,这种情况并非一成不变。从长远来看,我们可以安排在隔离模式下运行所有 CPU,前提是在内核进入时更新计时,并且调度程序的能力进一步增强,能够支持在用户空间中运行长时间的任务,而不需要远程中断才能保持统计信息的最新状态。但我们还没有做到。

内核进入/退出的开销


完全的 dynticks 模式增加了内核进入和退出的大量开销。这些是由于:

 

  • 系统调用

  • 异常(页面错误、陷阱等)

  • 中断

 

这些开销首先是由于 RCU 跟踪和排序造成的。这项工作通常由周期性计时器中断来处理。现在,我们已经摒弃了这种方法,最终需要使用代价高昂的完全排序后的原子操作,来计算通过内核边界的往返次数。

 

这些开销的第二部分来自记录CPU运行时间。同样,内核必须使用内核边界上的探测器来计算任务在内核和用户空间中执行所花费的时间,因为周期性的中断不再执行这项工作。尽管记录 CPU 运行时间使用的排序比 RCU 跟踪要弱,但仍有一些处理会增加总体开销。


我们之前曾经说过,IRQ 与内务管理密切相关。使用 mlock() 可以防止页面错误(https://man7.org/linux/man-pages/man2/mlockall.2.html)。之后,用户需要减少系统调用,这就形成了一条硬性规则:full dynticks 不适合基于内核的 I/O 型工作负载。相反,应将其保留给以下任一方:

 

  • CPU 计算型的工作负载。涉及大量 CPU 处理和最少的基于内核的 I/O 的操作(依赖内核驱动程序处理系统调用和中断)。

  • 对于内核不参与的 I/O 类型的工作负载,即基于 DPDK 等用户空间驱动程序的 I/O (https://www.dpdk.org/)。

结语


CPU 隔离和 full dynticks 可以为某些特定工作负载带来明显好处,但需注意,它在许多情况下并不适用。您必须特别注意以下两点:

 

  • 您需要牺牲一个隔离的 CPU,由其处理内核内部的无聊工作。

  • Full dynticks 仅适用于 CPU 计算型的工作负载,或者基于用户空间驱动程序的 I/O。


在第五篇文章中,我们将最终测试这一特性,并展示如何识别并调试其余的干扰。

2022-04-06 11:432047

评论

发布
暂无评论
发现更多内容

端到端的实时计算:TiDB + Flink 最佳实践

TiDB 社区干货传送门

实践案例

【文章】精选实践汇总1

TiDB 社区干货传送门

实践案例

Flink + TiDB,体验实时数仓之美

TiDB 社区干货传送门

实践案例

常见问题排查之 -- DM 主键冲突的原因及排查思路

TiDB 社区干货传送门

【TiDB 最佳实践系列】开发 Java 应用使用 TiDB 的最佳实践

TiDB 社区干货传送门

实践案例

某业务升级5.0解决慢SQL问题

TiDB 社区干货传送门

实践案例 故障排查/诊断

【TiDB 4.0 新 Feature 原理及实践】 Dashboard 触手体验

TiDB 社区干货传送门

如果你的 kubelet 运行在容器中,使用 local static provisioner 要注意一个问题

TiDB 社区干货传送门

5.0 新特性试用体验之 Clustered Index

TiDB 社区干货传送门

实践案例 TiDB 底层架构 版本测评 新版本/特性发布 性能测评

日本大型移动支付软件 PayPay 的 TiDB 迁移实践

TiDB 社区干货传送门

tiup目录冲突检测不健全导致的节点被destroy问题以及解决

TiDB 社区干货传送门

几分钟读懂 TiDB HTAP

TiDB 社区干货传送门

移动云基于 TiDB 实现 serverless 数据库服务

TiDB 社区干货传送门

tidb开发规范

TiDB 社区干货传送门

cdc 同步到 s3 的故障

TiDB 社区干货传送门

迁移 管理与运维 故障排查/诊断 新版本/特性发布

SQL只是CRUD?

TiDB 社区干货传送门

TiDB 底层架构

【热门问题】关于近期签名过期的处理合集

TiDB 社区干货传送门

AskTUG 论坛迁移实战:Discourse 从 PostgreSQL 到 MySQL 到 TiDB

TiDB 社区干货传送门

TiKV 集群部署 注意事项

TiDB 社区干货传送门

TiDB at ZaloPay Infrastructure & Lesson Learned

TiDB 社区干货传送门

PD 分配 TS 的 QPS 上限揭密

TiDB 社区干货传送门

【TiDB DevCon 2020】金融专题论坛演讲视频汇总

TiDB 社区干货传送门

TiDB 5.0 异步事务特性体验——基于X86和ARM混合部署架构

TiDB 社区干货传送门

NewSQL 在微众银行核心批量场景的应用

TiDB 社区干货传送门

实践案例

JQ 入门教程

TiDB 社区干货传送门

TiDB 底层架构

一次热点问题排查经历

TiDB 社区干货传送门

故障排查/诊断

写冲突场景下的悲观/乐观事务模型选择

TiDB 社区干货传送门

实践案例

TiDB 集群的可用性详解及 TiKV Label 规划

TiDB 社区干货传送门

TiDB 底层架构

PD模块梳理

TiDB 社区干货传送门

TiDB 底层架构

招募体验官!构建实时数仓 - 当 TiDB 遇见 Pravega

TiDB 社区干货传送门

TiDB 数据库开发规范

TiDB 社区干货传送门

CPU 隔离:管理和权衡_硬件_Frederic Weisbecker_InfoQ精选文章