CPU 隔离:管理和权衡

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

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
  • 根据您的扩展设置:
  1. 可以绑定的硬件 IRQ
  2. 除隔离的工作负载以外的用户任务

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

image.png

由于 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。

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

了解更多软件开发与相关领域知识,点击访问 InfoQ 官网:https://www.infoq.cn/,获取更多精彩内容!

目录
相关文章
|
4月前
|
存储 安全 虚拟化
【专栏】虚拟化技术将物理资源转化为虚拟资源,提高资源利用率和系统灵活性。
【4月更文挑战第28天】虚拟化技术将物理资源转化为虚拟资源,提高资源利用率和系统灵活性。通过服务器、存储和网络虚拟化,实现数据中心管理优化、云计算基础构建、企业IT成本降低及科研教育领域创新。尽管面临性能、安全挑战,但技术融合与创新、行业标准制定和可持续发展将推动虚拟化技术未来发展,为各领域带来更多可能性。
157 0
|
负载均衡 Linux API
CPU 隔离:实践
SUSE Labs 团队探索了 Kernel CPU 隔离及其核心组件之一:Full Dynticks(或 Nohz Full),并撰写了本系列文章。
714 0
|
资源调度 安全 Linux
安全与性能隔离|学习笔记
快速学习安全与性能隔离
180 0
|
Kubernetes Cloud Native 应用服务中间件
如何合理使用 CPU 管理策略,提升容器性能?
CPU Burst、拓扑感知调度是阿里云容器服务 ACK 提升应用性能的两大利器,它们解决了不同场景下的 CPU 资源管理,可以共同使用。点击下文,查看详情!
如何合理使用 CPU 管理策略,提升容器性能?
|
缓存 Linux 测试技术
CPU 隔离:简介
SUSE Labs 团队探索了 Kernel CPU 隔离及其核心组件之一:Full Dynticks(或 Nohz Full),并撰写了本系列文章。
432 0
CPU 隔离:简介
|
缓存 Kubernetes 负载均衡
谈CPU共享场景下的性能问题
背景容器化场景下,K8S (Kubernetes)调度器主导了单机上的资源布局,随之引入的是越来越多的多应用共享CPU场景,本文借着分析CPU共享的一些特征,引出其中存在的性能问题,并分析一些现有解法的思路和不足,做出展望。CPU的独享与共享OS提供Cgroup子系统以供用户进行资源管控,其中和CPU配置相关的有CPU和CPUSET两个子系统。 通常情况下一个容器内的应用会同时隶属于这两个子系统,
1214 0
|
存储 资源调度
《vSphere性能设计:性能密集场景下CPU、内存、存储及网络的最佳设计实践》一1.5.3 分布式资源调度
本节书摘来华章计算机《vSphere性能设计:性能密集场景下CPU、内存、存储及网络的最佳设计实践》一书中的第1章 ,第1.5.3节,[美] 克里斯托弗·库塞克(Christopher Kusek) 著 吕南德特·施皮斯(Rynardt Spies)姚海鹏 刘韵洁 译, 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1438 0
|
存储 测试技术
《vSphere性能设计:性能密集场景下CPU、内存、存储及网络的最佳设计实践》一3.3.4 定义IOmeter的工作负载和配置
本节书摘来华章计算机《vSphere性能设计:性能密集场景下CPU、内存、存储及网络的最佳设计实践》一书中的第3章 ,第3.3.4节,[美] 克里斯托弗·库塞克(Christopher Kusek) 著 吕南德特·施皮斯(Rynardt Spies)姚海鹏 刘韵洁 译, 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1516 0
|
存储 虚拟化
《vSphere性能设计:性能密集场景下CPU、内存、存储及网络的最佳设计实践》一1.5.4 高可用性
本节书摘来华章计算机《vSphere性能设计:性能密集场景下CPU、内存、存储及网络的最佳设计实践》一书中的第1章 ,第1.5.4节,[美] 克里斯托弗·库塞克(Christopher Kusek) 著 吕南德特·施皮斯(Rynardt Spies)姚海鹏 刘韵洁 译, 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1285 0