鲲鹏性能优化十板斧（二）——CPU与内存子系统性能调优

1.1 CPU与内存子系统性能调优简介调优思路性能优化的思路如下：l如果CPU的利用率不高，说明资源没有充分利用，可以通过工具（如strace）查看应用程序阻塞在哪里，一般为磁盘，网络或应用程序的业务处理中存在休眠或信号等待，这些优化措施在后续其它章节描述。l如果CPU利用率高，通过优化软件硬件的配置参数来更好适配业务场景，减少CPU占用率，让整...

华为云开发者联盟

5192人浏览 · 2019-11-08 14:45:11

华为云开发者联盟 · 2019-11-08 14:45:11 发布

1.1 CPU与内存子系统性能调优简介

调优思路

性能优化的思路如下：

l 如果CPU的利用率不高，说明资源没有充分利用，可以通过工具（如strace）查看应用程序阻塞在哪里，一般为磁盘，网络或应用程序的业务处理中存在休眠或信号等待，这些优化措施在后续其它章节描述。

l 如果CPU利用率高，通过优化软件硬件的配置参数来更好适配业务场景，减少CPU占用率，让整个系统有更多的CPU时间来处理业务。

我们也可以选择更好的硬件，根据CPU的能力配置合适的内存条，建议内存满通道配置，发挥内存最大带宽：一颗鲲鹏920处理器的内存通道数为8，两颗鲲鹏920处理器的内存通道数为16；建议选择高频率的内存条，提升内存带宽：鲲鹏920在1DPC配置时，支持的内存最高频率为2933MHz。

主要优化参数

优化项	优化项简介	默认值	生效范围	鲲鹏916	鲲鹏920
优化应用程序的NUMA配置	在NUMA架构下，CPU core访问临近的内存时访问延迟更低。将应用程序绑在一个NUMA节点，可减少因访问远端内存带来的性能下降。	默认不绑定核	立即生效	yes	yes
修改CPU预取开关	内存预取在数据集中场景下可以提前将要访问的数据读到CPU cache 中，提升性能；若数据不集中，导致预取命中率低，则浪费内存带宽。	on	重启生效	no	yes
调整定时器机制	nohz机制可减少不必要的时钟中断，减少CPU调度开销。	不同OS默认配置不同 Euler：nohz=off	重启生效	yes	yes
调整内存的页大小为64K	内存的页大小越大，TLB中每行管理的内存越多，TLB命中率就越高，从而减少内存访问次数。	不同OS默认配置不同: 4KB或64K	重新编译内核、更新内核后生效	yes	yes
优化应用程序的线程并发数	适当调整应用的线程并发数，使得充分利用多核能力和资源争抢之间达到平衡。	由应用本身决定	立即生效或重启生效（由应用决定）	yes	yes

1.2 常用性能监测工具

1.2.1 top工具

介绍

top是最常用的Linux性能监测工具之一。通过top工具可以监视进程和系统整体性能。

命令参考举例：

命令	说明
top	查看系统整体的CPU、内存资源消耗。
top执行后输入1	查看每个CPU core资源使用情况。
top执行后输入F，并选择P选项	查看线程执行过程中是否调度到其它CPU core。
top -p $PID -H	查看某个进程内所有线程的CPU资源占用。

安装方式

系统自带，无需安装。

使用方法

步骤 1 使用top命令统计整体CPU、内存资源消耗。

l CPU项：显示当前总的CPU时间使用分布。

us表示用户态程序占用的CPU时间百分比。
sy表示内核态程序所占用的CPU时间百分比。
wa表示等待IO等待占用的CPU时间百分比。
hi表示硬中断所占用的CPU时间百分比。
si表示软中断所占用的CPU时间百分比。

通过这些参数我们可以分析CPU时间的分布，是否有较多的IO等待。在执行完调优步骤后，我们也可以对CPU使用时间进行前后对比。如果在运行相同程序、业务情况下CPU使用时间降低，说明性能有提升。

l KiB Mem：表示服务器的总内存大小以及使用情况。

l KiB Swap：表示当前所使用的Swap空间的大小。Swap空间即当内存不足的时候，把一部分硬盘空间虚拟成内存使用。如果当前所使用的Swap空间大于0，可以考虑优化应用的内存占用或增加物理内存。

步骤 2 在top命令执行后按1，查看每个CPU core的使用情况。

通过该命令可以查看单个CPU core的使用情况，如果CPU占用集中在某几个CPU core上，可以结合业务分析触发原因，从而找到优化思路。

步骤 3 选中top命令的P选项，查看线程运行在哪些 CPU core上。

在top命令执行后按F，可以进入top命令管理界面。在该界面通过上下键移动光标到P选项，通过空格键选中后按Esc退出，即可显示出线程运行的CPU核。观察一段时间，若业务线程在不同NUMA节点内的CPU core上运行，则说明存在较多的跨NUMA访问，可通过NUMA绑核进行优化。

步骤 4 使用top -p $PID -H命令观察进程中每个线程的CPU资源使用。

“-p”后接的参数为待观察的进程ID。通过该命令可以找出消耗资源多的线程，随后可根据线程号分析线程中的热点函数、调用过程等情况

----结束

1.2.2 Perf工具

介绍

Perf工具是非常强大的Linux性能分析工具，可以通过该工具获得进程内的调用情况、资源消耗情况并查找分析热点函数。

命令参考举例：

命令	说明
perf top	查看当前系统中的热点函数。
perf sched record -- sleep 1 -p $PID	记录进程在1s内的系统调用。
perf sched latency --sort max	查看上一步记录的结果，以调度延迟排序。

安装方式

以CentOS为例，使用如下命令安装：

# yum -y install perf

使用方法

步骤 1 通过perf top命令查找热点函数。

该命令统计各个函数在某个性能事件上的热度，默认显示CPU占用率，可以通过“-e”监控其它事件。

l Overhead表示当前事件在全部事件中占的比例。

l Shared Object表示当前事件生产者，如kernel、perf命令、C语言库函数等。

l Symbol则表示热点事件对应的函数名称。

通过热点函数，我们可以找到消耗资源较多的行为，从而有针对性的进行优化。

步骤 2 收集一段时间内的线程调用。

perf sched record命令用于记录一段时间内，进程的调用情况。“-p”后接进程号，“sleep”后接统计时长，单位为秒。收集到的信息自动存放在当前目录下，文件名为perf.data。

步骤 3 解析收集到的线程调度信息。

perf sched latency命令可以解析当前目录下的perf.data文件。“-s”表示进行排序，后接参数“max”表示按照最大延迟时间大小排序。

----结束

1.2.3 numactl工具

介绍

numactl工具可用于查看当前服务器的NUMA节点配置、状态，可通过该工具将进程绑定到指定CPU core，由指定CPU core来运行对应进程。

命令参考举例：

命令	说明
numactl -H	查看当前服务器的NUMA配置。
numactl -C 0-7 ./test	将应用程序test绑定到0~7核运行。
numastat	查看当前的NUMA运行状态。

安装方式

以CentOS为例，使用如下命令安装：

# yum -y install numactl numastat

使用方法

步骤 1 通过numactl查看当前服务器的NUMA配置。

从numactl执行结果可以看到，示例服务器共划分为4个NUMA节点。每个节点包含16个CPU core，每个节点的内存大小约为64GB。同时，该命令还给出了不同节点间的距离，距离越远，跨NUMA内存访问的延时越大。应用程序运行时应减少跨NUMA访问内存。

步骤 2 通过numactl将进程绑定到指定CPU core。

通过 numactl -C 0-15 top 命令即是将进程“top”绑定到0~15 CPU core上执行。

可以通过numastat命令观察各个NUMA节点的状态。

l numa_hit表示节点内CPU核访问本地内存的次数。

l numa_miss表示节点内核访问其他节点内存的次数。跨节点的内存访问会存在高延迟从而降低性能，因此，numa_miss的值应当越低越好，如果过高，则应当考虑绑核。

----结束

1.3 优化方法

1.3.1 NUMA优化，减少跨NUMA访问内存

原理

通过1.1 鲲鹏处理器NUMA简介章节可以看到不同NUMA内的CPU core访问同一个位置的内存，性能不同。内存访问延时从高到低为：跨CPU > 跨NUMA不跨CPU > NUMA内

因此在应用程序运行时要尽可能的避免跨NUMA访问内存，我们可以通过设置线程的CPU亲和性来实现。

修改方式

l 网络可以通过如下方式绑定运行的CPU core，其中$cpuMask是16进制的数，最右边的bit表示core0；$irq为网卡队列中断号。

echo $cpuMask > /proc/irq/$irq/smp_affinity_list

l 通过numactl启动程序，如下面的启动命令表示启动test程序，只能在CPU core 28到core31运行(-C控制)。

numactl -C 28-31 ./test

l 在C/C++代码中通过sched_setaffinity函数来设置线程亲和性。

l 很多开源软件已经支持在自带的配置文件中修改线程的亲和性，例如nginx可以修改nginx.conf文件中的worker_cpu_affinity参数来设置nginx线程亲和性。

1.3.2 修改CPU的预取开关

原理

局部性原理分为时间局部性原理和空间局部性原理：

l 时间局部性原理（temporal locality）：如果某个数据项被访问，那么在不久的将来它可能再次被访问。

l 空间局部性原理（spatial locality）：如果某个数据项被访问，那么与其地址相邻的数据项可能很快也会被访问。

CPU将内存中的数据读到CPU的高速缓冲Cache时，会根据局部性原理，除了读取本次要访问的数据，还会预取本次数据的周边数据到Cache里面，如果预取的数据是下次要访问的数据，那么性能会提升，如果预取的数据不是下次要取的数据，那么会浪费内存带宽。

对于数据比较集中的场景，预取的命中率高，适合打开CPU预取，反之需要关闭CPU预取。目前发现speccpu和X265软件场景适合打开CPU预取，STREAM测试工具、Nginx和数据库场景需要关闭CPU预取。

修改方式

按照B 进入BIOS界面的步骤进入BIOS，然后在BIOS的如下位置设置CPU的预取开关。

1.3.3 定时器机制调整，减少不必要的时钟中断

原理

在Linux内核2.6.17版本之前，Linux内核为每个CPU设置一个周期性的时钟中断，Linux内核利用这个中断处理一些定时任务，如线程调度等。这样导致就算CPU不需要定时器的时候，也会有很多时钟中断，导致资源的浪费。Linux 内核2.6.17版本引入了nohz机制，实际就是让时钟中断的时间可编程，减少不必要的时钟中断。

修改方式

执行cat /proc/cmdline查看Linux 内核的启动参数，如果有nohz=off关键字，说明nohz机制被关闭，需要打开。修改方法如下：

修改前后，可以通过如下命令观察timer_tick的调度次数，其中$PID为要观察的进程ID，可以选择CPU占用高的进程进行观察：

perf sched record -- sleep 1 -p $PID

perf sched latency -s max

输出信息中有如下信息，其中591字段表示统计时间内的调度次数，数字变小说明修改生效。

timer_tick:(97) | 7.364 ms | 591 | avg: 0.012 ms | max: 1.268 ms

步骤 1 在“/boot”目录下通过find -name grub.cfg找到启动参数的配置文件。

步骤 2 在配置文件中将nohz=off去掉。

步骤 3 重启服务器。

----结束

1.3.4 调整内存页的大小为64K，提升TLB命中率

原理

TLB（Translation lookaside buffer）为页表（存放虚拟地址的页地址和物理地址的页地址的映射关系）在CPU内部的高速缓存。TLB的命中率越高，页表查询性能就越好。

TLB的一行为一个页的映射关系，也就是管理了一个页大小的内存：

TLB管理的内存大小 = TLB行数 x 内存的页大小

同一个CPU的TLB行数固定，因此内存页越大，管理的内存越大，相同业务场景下的TLB命中率就越高。

修改方式

修改Linux内核编译选项，并重新编译：

修改前后可以通过如下命令观察TLB的命中率（$PID为进程ID）：

perf stat -p $PID -d -d -d

输出结果包含如下信息，其中1.21%和0.59%分别表示数据的miss率和指令的miss率。

1,090,788,717      dTLB-loads                # 520.592 M/sec
13,213,603      dTLB-load-misses          #    1.21% of all dTLB cache hits
669,485,765      iTLB-loads                # 319.520 M/sec
3,979,246      iTLB-load-misses          #    0.59% of all iTLB cache hits

步骤 1 执行make menuconfig。

步骤 2 选择PAGESIZE大小为64K。

Kernel Features-->Page size(64KB)

步骤 3 编译和安装内核。

参考https://bbs.huaweicloud.com/forum/thread-24362-1-1.html

----结束

1.3.5 调整线程并发数

原理

程序从单线程变为多线程时，CPU和内存资源得到充分利用，性能得到提升。但是系统的性能并不会随着线程数的增长而线性提升，因为随着线程数量的增加，线程之间的调度、上下文切换、关键资源和锁的竞争也会带来很大开销。当资源的争抢比较严重时，甚至会导致性能明显降。下面数据为某业务场景下，不同并发线程数下的TPS，可以看到并发线程数达到128后，性能达到高峰，随后开始下降。我们需要针对不同的业务模型和使用场景做多组测试，找到适合本业务场景的最佳并发线程数。