Linux CPU锁频与绑核实战：从性能波动到稳定可复现

搞过Linux服务器的人应该都有这种经历：跑一个计算密集型的任务，明明CPU很强，但执行时间忽快忽慢，有时一次编译等得人心焦。打开top一看，频率在3.0GHz和4.5GHz之间跳来跳去，核心也一会儿满载一会儿歇着。如果只是日常用用倒也无所谓，可一旦涉及性能压测、实时数据处理、或者要给客户复现一个性能数据，这种"飘忽不定"的状态就很要命。

这篇文章要解决的，就是把Linux下的CPU频率和核心数真正"焊死"：固定在一个频率档位、只让任务跑在指定核心上。你会看到完整的排查思路、可复现的命令，以及我实测中踩过的坑。适合有Linux基础、但没系统性搞过CPU调优的运维和开发同学，也适合那些被基准测试数据波动折腾到头秃的测试工程师。

1. 为什么要把频率和核心数"焊死"：三个真实场景

1.1 频率飘忽不定带来的三类麻烦

现代CPU的调频机制非常激进。Intel的Turbo Boost、AMD的Precision Boost配合内核的cpufreq子系统，会在毫秒级别根据负载、温度、功耗余量来回调节频率。这套机制平时是好事，省电又凉快，但在下面几类场景里就是灾难。

第一个是基准测试不可复现。跑sysbench或者unixbench，第一次跑了100秒，第二次变成130秒，第三次又回到105秒。你以为代码有问题、环境有差异，实际上只是频率在测试过程中因为温度墙触发了降频，或者在负载变化时没有立刻冲到最高档。数据没法对齐，结论就没法给。

第二个是实时性无法保证。做音频处理、工业控制、高频交易这类延迟敏感的任务时，频率切换本身就有延迟。userspace和ondemand两种调度器的响应时间差异可能达到几十毫秒，对于要求微秒级响应的场景，这种不确定的调度行为直接导致丢帧、抖动、超时。

第三个是散热和功耗不可控。服务器放在机房还好，如果是工作站放在办公室，CPU频繁冲到最高频，风扇跟着起飞，噪音一阵一阵的。锁频之后，整机的功耗曲线变得平滑，散热压力也小很多。我自己有一台双路工作站，不锁频时待机35W，编译时能飙到280W，锁频4.0GHz后再跑同样任务，峰值功耗稳定在220W左右，风扇声音小了一圈。

1.2 锁定核心数解决的是另一类问题：资源争抢

频率锁的是"跑多快"，核心数锁的是"用哪几个核跑、怎么跑"。Linux内核的调度器默认会把进程在多个CPU核心之间迁移，来平衡负载。这个设计对普通桌面场景很合理，但对高性能计算来说，进程迁移带来的缓存失效代价非常大。

举个例子，一个进程在CPU2上跑，L2、L3缓存里全是它的数据。调度器为了平衡负载把它迁到CPU5，缓存瞬间全废，一切要从内存重新加载，性能可能直接掉20%。如果这个进程只绑定在CPU2上，缓存一直命中，速度反而稳定得多。

另外，中断处理程序默认都跑在CPU0上。如果CPU0同时还要处理你的业务进程，网卡中断一多，业务延迟就上去了。把核心业务绑到CPU2-CPU7，把中断留在CPU0/CPU1，两者互不干扰，这是很多高性能网关和数据库服务器的标准做法。

1.3 什么场景下才值得"锁死"

请注意，锁频和锁核都是有代价的——锁频会牺牲省电能力，锁核会浪费部分核心算力。所以先判断自己是不是真的需要。

如果你的目标是日常办公、编译代码、跑跑Docker，保持内核默认的ondemand或schedutil就挺好。但如果你是以下三类人，这套操作就是刚需：

• 性能测试工程师：需要可复现、误差可控的测试环境
• 实时/嵌入式开发：对调度延迟有硬性要求
• 服务器运维：希望CPU功耗曲线平滑、温度可控、关键业务与系统中断隔离

我自己的判断标准很简单：如果同一次操作在不同时间的耗时波动超过10%，锁频就是第一步排查手段。

2. 频率锁定前的摸底工作：搞清楚三件事再动手

2.1 查看CPU型号与当前频率状态

动手之前，先要弄清你的CPU到底长什么样。用lscpu看全貌：

lscpu

重点看这几行：

Architecture: x86_64 CPU(s): 16 On-line CPU(s) list: 0-15 Thread(s) per core: 2 Core(s) per socket: 8 Socket(s): 2 Model name: Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz CPU MHz: 2799.998 CPU max MHz: 3400.0000 CPU min MHz: 1200.0000

这里能获取的信息量很大。CPU max MHz和CPU min MHz给出了频率的理论边界，Thread(s) per core: 2表示开启了超线程，Socket(s): 2说明是双路平台，操作时要注意NUMA拓扑。

再看当前各核心的实时频率：

cat /proc/cpuinfo | grep -E "processor|MHz"

或者更直观地：

watch -n 1 "grep 'MHz' /proc/cpuinfo"

这个命令会把每个逻辑核的当前频率每秒刷新一次，是验证后面锁频是否生效最常用的手段。

2.2 确认当前cpufreq驱动和可用策略

Linux的调频是通过cpufreq框架实现的，它有一套驱动层，负责和具体硬件交互。查驱动类型：

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

最常见的输出是intel_pstate或acpi-cpufreq。这两个驱动差异很大，后面踩坑部分会详细说。再看当前系统支持的调频策略：

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

Intel平台常见的输出是：

performance powersave

注意，当使用intel_pstate驱动时，userspace和ondemand可能不会出现在这个列表里——这是Intel的限定，不是系统坏了。而AMD平台使用acpi-cpufreq驱动时，通常能看到：

conservative ondemand userspace powersave performance schedutil

再看当前正在使用的策略：

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

我的建议是，在做任何锁频操作前，把上面的输出保存一份，方便操作后对比。

2.3 列出可设置的频率档位：不是所有值都能直接写

很多人以为echo 4200000 > scaling_setspeed就能把频率设成4.2GHz，实际上CPU的频率通常是分档的。先看系统支持哪些频率：

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

Intel Xeon平台常见输出：

3400000 3300000 3200000 3100000 3000000 2900000 2800000 2700000 2600000 2500000 2400000 2300000 2200000 2100000 2000000 1900000 1800000 1700000 1600000 1500000 1400000 1300000 1200000

单位是kHz。如果scaling_available_frequencies为空，说明驱动没有暴露具体的频率表（HWP模式下经常这样），此时只能通过设置上下限或选择governor来间接控制。无论哪种情况，都不要凭感觉写一个不存在的频率值，内核会把它就近对齐到相邻档，搞不清状态时很容易得出"怎么没生效"的错误结论。

2.4 顺带确认核心编号与NUMA拓扑

锁定核心数之前，光看lscpu还不够，最好打印出逻辑CPU和物理核心的对应关系。两条命令：

lscpu -e lstopo-noarch --of png > cpu_topo.png

lscpu -e输出每一行的含义是：CPU是逻辑核编号，CORE是物理核编号，SOCKET是物理处理器编号，NODE是NUMA节点编号。例如输出：

CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ 0 0 0 0 0:0:0:0 yes 3400.0000 1200.0000 1 0 0 0 0:0:0:0 yes 3400.0000 1200.0000 2 0 0 1 1:1:1:1 yes 3400.0000 1200.0000 3 0 0 1 1:1:1:1 yes 3400.0000 1200.0000

CPU0和CPU1的CORE都是0，说明它们是同一个物理核的两个超线程，共享L1/L2缓存。这个信息在后面绑核时至关重要——一旦绑错，性能不升反降。

3. 频率锁定实战：从上到下的三层操作方法

3.1 先掌握通用的操作入口：sysfs接口

Linux把CPU调频的控制接口暴露在/sys/devices/system/cpu/cpuX/cpufreq/目录下。**不管用哪个工具，底层操作的都是这套接口。**常用的控制文件有：

• scaling_governor：选择调频策略
• scaling_setspeed：在userspace策略下手动指定频率值
• scaling_min_freq/scaling_max_freq：限制调频上下限
• energy_performance_preference：控制驱动偏向性能还是节能

直接操作sysfs是排查问题时的基本功，因为你随时可以精确知道当前状态。比如要把CPU0切到performance：

cpupower frequency-set -g performance

或者手动写sysfs：

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

注意用了tee而不是>，因为>是重定向，tee能以sudo权限写入多个文件。直接用echo > file配合sudo十有八九会碰到Permission denied，这是新手最容易卡住的地方。

3.2 方法一：performance策略锁最高频（最省事）

performance策略的意思是不论负载高低，始终把频率维持在最高档。这是最接近"锁频"的默认做法：

sudo cpupower frequency-set -g performance

验证：

grep "MHz" /proc/cpuinfo

正常情况下所有核心都会显示CPU max MHz对应的频率。这里有个容易误解的点：**就算governor是performance，CPU在空闲时依然可能进入C-state深度睡眠，表现出来就是频率显示很低。**这是硬件电源管理行为，不是governor失效。真正要让CPU始终保持在最高频率满负荷运转，通常还需要在内核启动参数里加intel_idle.max_cstate=0禁用深度C-state，这属于更深一层的电源管理调优，一般场景下不必做。

3.3 方法二：userspace策略锁指定频率（最精确）

performance虽然简单，但只能锁到最高频率，如果我想把一颗2.4GHz的E5-2640 v4锁在3.0GHz运行，降低发热和噪音，就得用userspace策略：

# 第一步：切换到userspace echo userspace | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor # 第二步：设定目标频率（单位kHz，3.0GHz写3000000） echo 3000000 | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_setspeed

第二步的频率值一定要填写系统支持的档位之一。如果填了3000000而可用频率里没有3.0GHz，内核会就近对齐到最近的档位，比如2900000或3100000。所以稳妥的操作是，先查看scaling_available_frequencies，然后从列表里选一个值：

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

因为频率文件分散在16个核的目录下，用循环一次性设置更高效：

for cpu in /sys/devices/system/cpu/cpu[0-9]*/cpufreq; do echo userspace | sudo tee $cpu/scaling_governor > /dev/null echo 3000000 | sudo tee $cpu/scaling_setspeed > /dev/null done

验证方式还是老办法，看/proc/cpuinfo里的MHz字段，连续观察几秒确认频率稳定在3000MHz左右。

3.4 方法三：用cpupower工具一步到位

cpupower是Linux内核自带的管理工具，底层封装了sysfs操作，还带了统计功能。我日常用得最多的就是它，因为它一条命令就能同时处理所有核心：

# 安装（Debian/Ubuntu） sudo apt install linux-tools-common linux-tools-$(uname -r) # 锁到最高频 sudo cpupower frequency-set -g performance # 锁到指定频率（userspace模式） sudo cpupower frequency-set -g userspace -f 3000MHz # 设置频率上下限 sudo cpupower frequency-set -d 3000MHz -u 3000MHz

cpupower frequency-set -d和-u分别对应最低和最高频率限制，这在部分驱动下比切换governor更灵活。例如驱动不支持userspace时，可以直接把上下限都设成同一个值，效果等价于锁频。

用cpupower工具时有个版本匹配问题，工具版本和内核版本不一致会报WARNING: ACPI CPPC driver failed之类的提示。解决办法不是急着换工具，而是先确认cpupower frequency-info能不能正常输出频率信息。

3.5 验证锁频是否真的生效：连续观察与压力测试

设置完不等于生效，必须压一下测试稳定性。用sysbench制造负载，同时观察频率曲线：

sudo apt install sysbench sysbench cpu --threads=16 --time=60 run & watch -n 1 "grep 'MHz' /proc/cpuinfo"

锁频成功的标志是：60秒内所有核心的MHz值基本不变，且保持在你设定的目标频率附近。如果频率在波动，说明governor没有真正切过去，或者被某个守护进程覆盖了设置。这时候需要检查下一步的systemd服务和tuned服务是否在背地里搞事情。

4. 核心数锁定实战：从轻量绑核到内核级隔离

4.1 进程级绑核：taskset命令就够了

最简单的绑核方式是用taskset。它通过设置进程的CPU亲和性（affinity），让进程只运行在指定的核心上。

启动新进程时绑定：

# 绑定到CPU0和CPU2 taskset -c 0,2 ./my_server # 绑定到CPU4到CPU7 taskset -c 4-7 ./my_server

对已经在运行的进程绑定：

# 找到进程PID后绑定 sudo taskset -pc 0,2 12345

查看进程当前绑核情况：

taskset -pc 12345

输出示例：

pid 12345's current affinity list: 0,2

taskset的好处是简单直接，不需要额外配置，随时可以临时改。坏处是只影响单个进程，如果my_server会fork一堆子进程，子进程不继承亲和性设置的话，还是要逐个绑定，管理起来很麻烦。

4.2 更彻底的方案：用cpuset cgroup做核心分组

如果想把一个进程连同它的所有子进程，以及该进程可能fork出来的所有线程，统一限制在一组核心上，taskset就不够看了，得用cgroup的cpuset子系统。

现代Linux发行版基本都用cgroup v2，配置方式如下：

# 创建cpuset控制器目录 sudo mkdir /sys/fs/cgroup/cpuset # 挂载cgroup v2（如果还没挂载） sudo mount -t cgroup2 none /sys/fs/cgroup # 在cgroup根下创建隔离组 sudo mkdir /sys/fs/cgroup/isolated # 把隔离组的核心范围设置成CPU0和CPU2 echo "0,2" | sudo tee /sys/fs/cgroup/isolated/cpuset.cpus # 把NUMA内存节点设置为节点0（如果系统有多个节点） echo "0" | sudo tee /sys/fs/cgroup/isolated/cpuset.mems # 把目标进程PID加入隔离组 echo 12345 | sudo tee /sys/fs/cgroup/isolated/cgroup.procs

设置之后，PID 12345及它后续创建的所有线程，都只能在CPU0/CPU2上运行。与taskset最大的区别是，cpuset能做到一种"物理隔离"：这部分核心上不会再有其他普通进程被调度上来，除非其他进程也手动加入同一个cpuset组。这在高性能数据库、JVM应用调优时很常用，比如给JVM独占8个核，剩余的核留给系统和中间件。

4.3 内核级隔离：isolcpus启动参数

如果服务器是专用环境，可以更进一步，在系统启动阶段就告诉内核：某些核心不要做普通调度。在GRUB配置中修改内核启动参数：

isolcpus=2,3 nohz_full=2,3 rcu_nocbs=2,3

添加方法：

sudo vim /etc/default/grub

找到GRUB_CMDLINE_LINUX这一行，把参数加进去：

GRUB_CMDLINE_LINUX="isolcpus=2,3 nohz_full=2,3 rcu_nocbs=2,3"

然后更新GRUB并重启：

sudo update-grub # Debian/Ubuntu sudo reboot

重启后用lscpu查看核心2、3的在线状态，再用taskset -pc $$随便看一个进程，你会发现系统已经默认把普通进程的全集亲和性设置为除2、3之外的核心。isolcpus的效果是让内核调度器不再自动把用户进程分配到这些核心上，但它们仍然在线、仍然可以接受用户手动绑定的任务。

nohz_full让这些核心关闭周期性时钟中断，rcu_nocbs把RCU回调从这个核心上挪走。这三件套配合使用，是Linux上实现近乎"无干扰"实时计算的标准姿势。代价是这些核心上跑的任务出问题后，系统日志不一定会及时打印，排查难度增加，所以只建议在专用场景下开启。

4.4 直接关闭核心：CPU hotplug

最暴力的"锁核"方式是把不需要的核心直接关掉。Linux支持运行时热插拔CPU：

# 关闭CPU3 echo 0 | sudo tee /sys/devices/system/cpu/cpu3/online # 重新开启 echo 1 | sudo tee /sys/devices/system/cpu/cpu3/online

关掉之后，/proc/cpuinfo里就没有processor 3了，内核也完全不会往这个核心上分配任何任务。这种方法适合需要"绝对彻底隔离"的场景，比如跑一个对延迟极度敏感的进程，不想让任何系统守护进程、软中断、RCU回调落在指定核心上。

但要注意：关闭核心后核间通信、中断重定向会有短暂的性能波动，生产环境别在业务高峰期乱关。另外，CPU online操作依赖ACPI，部分服务器固件策略会阻止关核，遇到echo 0后文件内容不变的情况，别硬来，改用isolcpus。

4.5 用systemd管理进程级CPU亲和性

如果你用的是systemd管理的服务，无需脚本，直接在unit文件里声明绑核：

[Service] CPUAffinity=2,3

执行systemctl daemon-reload && systemctl restart myservice后，服务的所有进程都会自动绑定到CPU2和CPU3。这是最推荐的生产环境做法，因为它把配置声明化、可审计，不像临时命令那样重启就丢。

5. 持久化设置：让锁频锁核重启后依然生效

5.1 借助systemd服务实现开机自启

锁频和绑核的命令重启后都会失效，所以生产环境必须做成开机任务。我通常写一个独立的systemd unit：

[Unit] Description=Set CPU governor and affinity After=multi-user.target [Service] Type=oneshot ExecStart=/usr/local/bin/cpu_lock.sh RemainAfterExit=yes [Install] WantedBy=multi-user.target

脚本/usr/local/bin/cpu_lock.sh内容：

#!/bin/bash # 锁频 cpupower frequency-set -g performance # 如果使用userspace指定频率，取消下面行的注释 # cpupower frequency-set -g userspace -f 3000MHz # 将业务进程绑定到指定核心 # taskset -pc 0,2 $(pgrep myserver)

给脚本加可执行权限后启动服务：

sudo chmod +x /usr/local/bin/cpu_lock.sh sudo systemctl daemon-reload sudo systemctl enable cpu-lock.service sudo systemctl start cpu-lock.service

这个方案的好处是顺序可控，After=multi-user.target保证网络和基础服务已经就绪。

5.2 发行版的专用配置：Debian/Ubuntu的cpufrequtils

Debian/Ubuntu系统还有一个更省事的方式，安装cpufrequtils后直接改配置文件：

sudo apt install cpufrequtils sudo vim /etc/default/cpufrequtils

文件里写入：

GOVERNOR="performance"

保存后重启，系统就会按这个governor策略启动。如果要指定频率，需要配合/etc/init.d/cpufrequtils的脚本调整，兼容性不如sysfs手动方案稳定，新手建议直接用systemd方案。

5.3 排查"设置被自动重置"的元凶：tuned与thermald

我在第3步强调过，明明设置了performance，过几分钟就变回schedutil或ondemand，是锁频操作中最诡异的问题。罪魁祸首通常是tuned或thermald。

tuned是Red Hat系发行版的动态调优守护进程，它会周期性地根据当前"profile"（如balanced、throughput-performance）调整CPU、磁盘、网络的参数。thermald是Intel的温度守护进程，会检测温度并主动限制频率防止过热。这两兄弟都会在后台覆盖你手工写进sysfs的配置。

排查方法：

# 查看tuned状态 systemctl status tuned # 查看当前生效的profile tuned-adm active # 临时关闭tuned sudo systemctl stop tuned sudo systemctl disable tuned

对于thermald，如果是Intel平台且确实有散热压力，不建议直接禁用，而是把锁频值设低一点，让thermald的干预余量变小。如果确认没有散热问题，可以停用：

sudo systemctl stop thermald sudo systemctl disable thermald

还有一个隐蔽的覆盖源：/etc/tmpfiles.d/里某些配置会在开机时写入CPU相关参数，检查一下是否有相关文件，有就一并删除。

5.4 验证重启后配置是否生效

配置完开机自启，不要急着当甩手掌柜。重启一次，然后跑完整的验证链路：

# 1. 查看governor cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # 2. 查看频率 grep "MHz" /proc/cpuinfo # 3. 查看进程亲和性（如果绑了核） taskset -pc $(pgrep myserver) # 4. 跑一个压力测试，确认稳定性 sysbench cpu --threads=16 --time=30 run

只有这四步全部符合预期，这套配置才算真正落地。

6. 踩坑实录：三次真实排查，每一条都是教训

6.1 坑一：Intel平台的HWP导致锁频无效

有一台Intel i7-9700K的机器，我按标准操作设置performance后，/proc/cpuinfo里频率依然在4.8GHz和5.0GHz之间跳动。排查了很久，最后在dmesg里看到：

intel_pstate: HWP enabled

问题就出在这里。较新的Intel CPU支持硬件控制功耗状态（HWP），此时主导频率决策的是CPU内部硬件，Linux的cpufreq驱动只能做"软约束"。performancegovernor在这个模式下并不保证锁定某个具体频率。

解法有两个。一是禁用HWP，在内核参数里加：

intel_pstate=disable

或

intel_pstate=passive

禁用后驱动会退回到acpi-cpufreq，userspace策略就能真正锁定指定频率档位。二是接受硬件HWP，只通过energy_performance_preference设置性能偏好：

echo "performance" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference

这样设置的效果是让CPU硬件在功耗允许范围内尽量跑高频，但不保证稳定在一个值。如果只是追求"尽量快"，第二种方式就够用；如果要精确锁频，必须走第一种。

6.2 坑二：超线程编号陷阱，绑核后性能不升反降

我用taskset -c 0,2把一个多线程程序绑在两个核上，结果吞吐量比不绑还低，离谱。用lscpu -e一看才明白，逻辑核0和逻辑核2其实是同一个物理核上的两个超线程，它们共享同一个物理核心的ALU执行单元，两个进程挤在一起当然快不了。

正确的绑核方式应该优先选择不同的物理核心。比如物理核0对应逻辑核0/1，物理核1对应逻辑核2/3，那taskset -c 0,2看似"两个核"，其实是同一个物理核。应该绑taskset -c 0,3或者根据实际架构选不同物理核对应的逻辑核。

我的建议：绑核之前一定先跑一遍lscpu -e，画出核心和线程的对应关系，再决定绑哪些编号。这是最容易被忽视、又最容易造成性能灾难的细节。

6.3 坑三：用户态工具版本与内核不匹配导致误判

有一段时间我执行cpupower frequency-info，输出里全是：

WARNING: Unable to detect current CPU frequency

一度以为内核调频驱动坏了。后来发现是linux-tools版本和内核版本对不上，工具读取/dev/cpu_dma_latency或者访问msr设备时失败。解决办法不是换工具，而是装对应内核版本的tools包：

sudo apt install linux-tools-$(uname -r)

如果uname -r对应的包不存在，就用最新的通用包，同时检查msr模块是否加载：

sudo modprobe msr

顺带说一句，在虚拟机里做这些实验会踩到另一层坑：虚拟化平台通常不把真实CPU频率暴露给guest，/proc/cpuinfo里的MHz可能恒定且不可控。所以做锁频实验，尽量用物理机，别用VM。

6.4 附加提醒：锁频后温度与功耗监控不能省

把频率锁高之后，功耗和发热一定上升。建议同时监控温度：

sudo apt install lm-sensors sudo sensors-detect --auto sensors

如果锁在最高频后温度超过85°C，就要权衡是继续锁频还是降一档。在这里我的经验是：锁频锁的是上限，不是让你无条件跑满。如果散热压不住，宁可选择比最高档低一档的频率，也不要锁在最高档然后摸到温度墙触发保护性降频，那反而比不锁更不稳定。

7. 一套可复用的完整操作流程

把上面的内容串起来，我在新的服务器上做锁频锁核时，基本按这套流程走：

1. 摸底：lscpu、cat /proc/cpuinfo | grep MHz、cpupower frequency-info
2. 确认驱动和策略：查scaling_driver、scaling_available_governors
3. 锁频：优先cpupower frequency-set -g performance测一轮，要求精确档位再切userspace
4. 绑核：用lscpu -e画好核心地图，再taskset或systemdCPUAffinity
5. 持久化：写systemd服务，禁用tuned/thermald干扰
6. 验收：重启后跑sysbench，确认频率稳定、核心在线、进程亲和性正确

这套流程走下来大概20分钟，但能省下后续无数个"怎么测试数据又跳了"的夜晚。拿我自己的机器举例，锁频到3.4GHz、进程绑定到CPU0-CPU7之后，跑同样的压测，时间误差从原来的正负15%缩小到了2%以内，这才敢拿数据出去给别人看。

提示：对任何生产服务器做频率和核心调整前，建议先在测试机上验证整个流程。特别是内核启动参数（如isolcpus、intel_pstate=disable）一旦配错，可能导致开机失败。到那时候别慌，进GRUB菜单在启动项上按e编辑参数，删掉有问题的部分进入系统再修正即可。

最后再分享一个小技巧。如果你既想要性能又不想整天手动切，可以在脚本里写两个函数：perf_mode()切到锁频锁核，eco_mode()切回schedutil并清空绑核设置。压测之前切到perf_mode，平时用eco_mode，两边的好处都能吃到。在实际操作中，快捷键绑定这两个函数是我用得最频繁的日常操作。