为何首次运行的基准测试总是延迟更低？线程绑定性能排查

核心现象 #

无论默认线程绑定测试还是优化绑定测试，先运行的测试耗时始终比后运行的低约20%，缓存清空、预热、两次测试间休眠均无法改变该规律，单测试耗时约2.5秒，重复20次结果一致。

最可能的原因：CPU睿频功率限制 #

你的服务器是Intel Cascade Lake双路CPU，这类处理器的Turbo Boost（睿频）存在两种关键功率限制：

• PL2（短时间功率限制）：允许CPU在数秒内以远高于基础频率的峰值睿频运行，功耗可达PL1（持续功率限制）的1.5-2倍。
• PL1（持续功率限制）：长时间运行时，CPU必须降到PL1对应的频率，避免功耗和温度超标。

你的单测试时长约2.5秒，刚好落在PL2的允许窗口内：

1. 第一次测试启动时，CPU处于低功耗/idle状态，能立刻触发PL2级别的最高睿频，全程以高频运行，耗时更短。
2. 第一次测试结束后，CPU功耗已接近或达到PL1上限，第二次测试启动时无法再触发PL2睿频，只能以PL1对应的基础/持续睿频运行，导致耗时增加约20%。

调换测试顺序后，同样是第一次测试占用PL2窗口，因此总是更快。

其他可能的辅助因素 #

• C-state/P-state切换延迟：CentOS7默认的cpufreq governor如果是powersave或ondemand，CPU idle时会降到低频，第一次测试启动时的频率切换刚好赶上PL2触发时机，而第二次测试时CPU已处于持续运行状态，无法再提升到最高睿频。
• NUMA内存分配残留：第一次测试时，内存被分配到线程绑定的本地NUMA节点（同socket），第二次测试时可能因系统内存碎片导致部分内存分配到远程NUMA节点，但该因素的性能差距通常小于20%，优先级低于睿频限制。

验证与解决方法 #

验证方法 #

1. 用perf stat -e cpu-clock,cycles分别统计两次测试的CPU周期数和时钟时间，如果第一次测试的cycles / cpu-clock比值远高于第二次，说明第一次运行时CPU频率更高。
2. 查看CPU功率限制配置：执行cpupower info，查看PL1和PL2的数值及持续时间。

解决方法 #

1. 锁定CPU频率到最高睿频：
   • 临时修改：cpupower frequency-set --governor performance，该命令会让CPU始终运行在最高支持频率，消除功率限制带来的影响。
   • 永久修改：编辑/etc/default/cpupower，设置GOVERNOR="performance"，然后重启cpupower服务。
2. 调整PL1/PL2限制：
   • 若服务器支持，可通过BIOS设置提高PL1的功率上限，让CPU能持续以更高频率运行。
   • 部分Linux内核支持通过sysfs调整：echo performance > /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference（需对应内核版本支持）。
3. 延长两次测试的间隔时间：
   • 把休眠时间增加到10秒以上，让CPU功耗降到PL1以下，恢复PL2的触发能力后再运行第二次测试。

补充说明 #

你的缓存清空操作仅针对数据缓存（L1/L2/L3），但无法影响CPU的功率/频率状态，这也是缓存操作无法解决问题的核心原因。而线程绑定本身的开销极小，不足以导致20%的性能差距。

内容的提问来源于stack exchange，提问作者avernus