Show Table of Contents
第 3 章 CPU
本章对红帽企业版 Linux 7 中会影响应用性能的 CPU(中央处理器)硬件细节及配置选择进行了概述。<第 3.1 节 “注意事项” >详述了与 CPU 相关的会影响性能的因素。 <第 3.2 节 “监控和诊断性能问题” >教您如何使用红帽企业版 Linux 7 的工具来诊断与 CPU 硬件或配置细节相关的性能问题。< 第 3.3 节 “配置建议”> 详述了可用以解决在红帽企业版 Linux 7 中与 CPU 相关的性能问题的工具和策略。
3.1. 注意事项
阅读本章来了解以下因素是如何影响系统和应用程序性能的。
- 处理器如何互相连接,并且如何连接到相关资源,如内存。
- 处理器如何为执行操作调度线程。
- 处理器如何处理红帽企业版 Linux 7 中的间断。
3.1.1. 系统拓扑
在现代计算机技术中,一个"中央"处理单元的观念是误导性的,因为大部分现代化的系统都有多个处理器。这些处理器是如何相互连接,并且如何连接至其他系统资源 —"系统拓扑"— 会对系统和应用程序的性能以及系统调节选项产生巨大的影响。
现代计算机技术主要运用两种主要的拓扑类型
- SMP 拓扑
- SMP(对称多处理器)拓扑允许所有的处理器同时访问内存。然而,由于内存访问权限的共享性和平等性,固然会迫使所有 CPU 及 SMP 系统序列化的内存访问权限的局限性增加,目前这种情况常不被接受。因此,几乎所有现代服务器系统都是 NUMA(非一致性内存访问)机器。
- NUMA 拓扑
- 比起 SMP 拓扑,NUMA(非一致性内存访问)拓扑是近来才开发的。在 NUMA 系统中,多个处理器物理分组至一个 socket。每个 socket 都有一个专用内存区,对该内存进行本地访问的服务器统称为一个节点。同一个节点上的服务器能高速访问该节点的存储体,但访问其他节点上的存储体速度就较慢。因此,访问非本地存储体会造成性能的损失。考虑到性能损失,服务器执行应用程序时,NUMA 拓扑结构系统中对性能敏感的应用程序应访问同一节点的内存,并且应尽可能地避免访问任何远程内存。因此,在调节 NUMA 拓扑结构系统中的应用程序性能时,重要的是要考虑这一应用程序的执行点以及最靠近此执行点的存储体。在 NUMA 拓扑结构系统中,
/sys文件系统包含处理器、内存及外围设备的连接信息。/sys/devices/system/cpu目录包含处理器在系统中相互连接的详情。/sys/devices/system/node目录包含系统中 NUMA 的节点信息以及节点间的相对距离。
3.1.1.1. 确定系统拓扑结构
很多指令能帮助用户了解系统的拓扑结构。
numactl --hardware 指令概述了系统的拓扑结构。
$ numactl --hardware available: 4 nodes (0-3) node 0 cpus: 0 4 8 12 16 20 24 28 32 36 node 0 size: 65415 MB node 0 free: 43971 MB node 1 cpus: 2 6 10 14 18 22 26 30 34 38 node 1 size: 65536 MB node 1 free: 44321 MB node 2 cpus: 1 5 9 13 17 21 25 29 33 37 node 2 size: 65536 MB node 2 free: 44304 MB node 3 cpus: 3 7 11 15 19 23 27 31 35 39 node 3 size: 65536 MB node 3 free: 44329 MB node distances: node 0 1 2 3 0: 10 21 21 21 1: 21 10 21 21 2: 21 21 10 21 3: 21 21 21 10
lscpu 指令由 util-linux 数据包提供,包括 CPU 体系结构信息,如 CPU 数量、线程数、内核数、 socket 数量以及 NUMA 节点数等。
$ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 40 On-line CPU(s) list: 0-39 Thread(s) per core: 1 Core(s) per socket: 10 Socket(s): 4 NUMA node(s): 4 Vendor ID: GenuineIntel CPU family: 6 Model: 47 Model name: Intel(R) Xeon(R) CPU E7- 4870 @ 2.40GHz Stepping: 2 CPU MHz: 2394.204 BogoMIPS: 4787.85 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 30720K NUMA node0 CPU(s): 0,4,8,12,16,20,24,28,32,36 NUMA node1 CPU(s): 2,6,10,14,18,22,26,30,34,38 NUMA node2 CPU(s): 1,5,9,13,17,21,25,29,33,37 NUMA node3 CPU(s): 3,7,11,15,19,23,27,31,35,39
lstopo 指令由 hwloc 数据包提供,创建了用户的系统示意图。lstopo-no-graphics 指令提供详尽的文本输出。

lstpo 指令的输出
3.1.2. 调度
在红帽企业版 Linux 中,执行进程的最小单元叫做一个 “线程”。系统调度器决定运行线程的处理器和运行的时间。但由于调度器主要关注的是保持系统繁忙,因此可能不会为应用程序的性能而对线程进行最佳调度。
例如,在 NUMA 系统中,一个处理器在节点 B 可用,一个应用程序在节点 A 运行,要使在节点 B 的处理器保持忙碌, 调度器会把应用程序的一个线程转移到节点 B。但是,线程上的应用程序仍然需要访问在节点 A 的内存。由于该线程目前在节点 B 运行,并且对于此线程来说节点 A 的内存已不再是本地内存,访问起来就要花更长的时间。较于在节点 A 等待可用的处理器,并且在能够进行本地内存访问的源节点上执行线程,此线程在节点 B 结束运行可能就更加费时。
设计器或管理员确定线程的运行位置能使对性能敏感的应用程序从中受益。如何保证适当地调度线程,以满足对性能敏感的应用程序的需要,详情请参见 <第 3.3.6 节 “调节调度策略”>。
3.1.2.1. 内核滴答信号
在早期红帽企业版 Linux 版本中,Linux 内核会定期中断每个 CPU 以查看需要完成的任务。查看的结果用来决定进程调度及负载均衡。这种常规性的中断叫做一个内核 “滴答信号”。
此标记的出现不考虑内核是否有任务要执行。这意味着为了回应这些中断,即使是空闲的内核也会被迫定期进入高能状态(每秒高达1000次)。这阻止了系统有效地利用新近 x 86 代处理器的深睡眠状态。
在红帽企业版 Linux 6 和 7 中,默认情况下内核不再中断趋于低功率状态的空闲 CPU,这种性能叫做无时钟内核。当一个或几个任务在运行时,按需中断取代了定时中断,使 CPU 可以更久地处于空闲或低功率状态,减少了电量的消耗。
红帽企业版 Linux 7 提供一种动态的无时钟设置(
nohz_full ),通过用户空间的任务来减少内核干扰以进一步改善其确定性。这一设置可以在指定的内核中通过 nohz_full 内核参数来启用。当这一设置在一个内核中启用时,所有的计时活动将会被移动至无延迟敏感性的内核。这对于高性能计算和实时计算工作负载来说都很有用,因为其用户空间任务对由于内核计时器滴答信号造成的微秒级的延迟尤为敏感。
启用红帽企业版 Linux 7 中动态无时钟性能的方法,请见< 第 3.3.1 节 “配置内核滴答记号时间”>。
3.1.3. 中断请求管理
中断请求或 IRQ 是请求及时关注的信号,是从硬件发送至处理器的。系统中的每个设备都分配到一个或多个 IRQ 号,以便能发送独一的中断信号。当启用中断时,收到中断请求的处理器会立即暂停执行当前应用程序线程,这是为了处理该中断请求。
因为中断了正常的运行,高中断率会严重降低系统性能,但减少中断的时间是可能的,可以设置中断关联或发送一批低优先率的中断(“组合 中断”)
关于调节中断请求的更多信息,请见< 第 3.3.7 节 “设置中断关联”> 或 <第 3.3.8 节 “使用 Tuna 配置 CPU、线程和中断关联”>。针对网络中断信息,请见< 第 6 章 网络>。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.