服务器CPU频率|kuuhaku的博客

主频：CPU 的标称基础频率（可以长时间达到的）

睿频：短时间内动态提升的峰值频率

关键区别

特性	主频 (基础频率)	睿频 (加速频率)
核心定义	长时间稳定运行的基础频率	短时间内动态提升的峰值频率
稳定性	持续稳定运行，厂家保证	临时、动态提升，依赖条件
目的	提供基准性能，保证稳定运行	按需提升性能（尤其单/少线程），改善响应速度
持续时间	长期	短期 (视负载、温度、功耗而定)
依赖条件	标准散热和供电即可	严重依赖负载、温度、功耗、供电、散热、CPU体质
多核场景	所有核心满载时通常运行在基础频率	部分核心（1个、几个或全部）在条件允许时可加速
功耗/发热	在标准TDP范围内	加速时功耗和发热显著高于基础频率运行
用户视角	CPU 的“保底速度”	CPU 的“加速能力”或“爆发力”

查看服务器cpu主频

查看标称主频（官方参数）

lscpu | grep "Model name"
lscpu | egrep "Model name|CPU max MHz|CPU min MHz"

若输出如下，无频率信息

root@114514:~# lscpu | grep "Model name"
Model name:                           AMD EPYC 7702 64-Core Processor

则用dmidecode

sudo dmidecode -t processor | grep "Speed"

没装dmidecode就安装一下

sudo apt install dmidecode -y

dmidecode 会显示两个关键值：

Max Speed：CPU 的标称基础频率（即主频）
Current Speed：当前 BIOS 报告的运行频率（通常与基础频率一致）

实时频率（单位是MHz与GHz之间是1000转换关系）

cat /proc/cpuinfo | grep "cpu MHz"

使用虚拟化的

例子

root@114514:~# lscpu | grep "Model name"
Model name:                         Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
BIOS Model name:                    RHEL 7.4.0 PC (i440FX + PIIX, 1996)  CPU @ 2.0GHz
root@114514:~# sudo dmidecode -t processor | grep "Speed"
	Max Speed: 2000 MHz
	Current Speed: 2000 MHz

这解释了为什么dmidecode显示的信息与CPU实际规格不一致。分析一下这些结果：

关键信息分析

CPU 实际型号：
```
Model name: Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
```
- 这是物理服务器的真实CPU：Intel Xeon Gold 6148
- 官方基础频率：2.40 GHz（2400 MHz）
- 官方最大睿频：3.70 GHz
虚拟化环境信息：
```
BIOS Model name: RHEL 7.4.0 PC (i440FX + PIIX, 1996) CPU @ 2.0GHz
```
- 您使用的是 KVM/QEMU 虚拟化环境（i440FX芯片组是QEMU的经典配置）
- 虚拟机看到的CPU是虚拟化的：@ 2.0GHz
dmidecode 输出：
```
Max Speed: 2000 MHz
Current Speed: 2000 MHz
```
- 这与虚拟化环境报告一致
- 不是真实物理CPU的频率

结论：为什么显示2.0GHz而不是2.4GHz

您处于虚拟化环境中
- 云服务商/虚拟化平台限制了CPU资源
- 虚拟机看到的CPU是虚拟化的"占位符"CPU，不是真实硬件
CPU频率被限制
- 虚拟化层将CPU频率限制在2.0GHz
- 这是云服务商常见的资源分配策略
性能影响
- 您的应用最高只能使用2.0GHz频率
- 无法利用真实CPU的睿频能力(3.7GHz)

获取真实频率的方法

查看物理主机信息（需要云服务商支持）：

# 尝试获取物理节点信息
cat /sys/devices/virtual/dmi/id/product_name

# 查看CPU微码版本（可能揭示真实型号）
grep microcode /proc/cpuinfo | uniq

监控实际性能：

# 安装监控工具
sudo apt install sysstat -y

# 实时查看CPU利用率+频率
watch -n 1 "grep 'cpu MHz' /proc/cpuinfo | sort -n | tail -1; mpstat -P ALL 1 1"

压力测试验证上限：

# 安装压力测试工具
sudo apt install stress -y

# 运行单核满载测试
stress -c 1 &

# 观察最高频率
watch "grep 'cpu MHz' /proc/cpuinfo | sort -n | tail -1"

建议操作

联系云服务商：
- 确认是否提供更高频率的实例类型
- 询问是否可关闭频率限制

在虚拟机内优化：

# 设置性能模式（可能提升频率）
sudo apt install cpufrequtils -y
sudo cpufreq-set -g performance

# 检查当前调节器
cpufreq-info -o

接受资源限制：
- 大多数云服务器都有CPU限制
- 2.0GHz是常见的"基准频率"分配

⚠️ 注意：云服务商通常不会让虚拟机使用物理CPU的全速能力，2.0GHz的限制是常见的设计选择，旨在保证多租户公平性。

实时频率高于限制频率

root@114514:~# cat /proc/cpuinfo | grep "cpu MHz"
cpu MHz		: 2394.374
cpu MHz		: 2394.374

这揭示了虚拟化环境中CPU频率管理的复杂性。详细解释这个看似矛盾的现象：

为什么显示2394 MHz（2.39GHz）而不是2000 MHz？

虚拟化层的动态频率管理
- 云平台（如您使用的）使用CPU配额和突发机制
- 当虚拟机有负载时，可以临时突破基础频率限制
- 您看到的2394 MHz是当前实际运行频率

两种不同的限制机制

graph LR
A[物理CPU] -->|虚拟化层| B[虚拟CPU]
B --> C[dmidecode报告的基础频率 2000MHz]
B --> D[/proc/cpuinfo实时频率 2394MHz]

具体技术解释
- dmidecode 显示的是保证的最低频率（2000 MHz）
- /proc/cpuinfo 显示的是当前实际频率（可达物理CPU最大能力）
- 云平台允许虚拟机短期突发到更高频率

验证频率限制的实验

创建持续负载

# 安装压力测试工具
sudo apt install stress -y

# 启动一个持续的高负载（使用所有CPU核心）
stress -c $(nproc) &

监控频率变化

# 每0.5秒刷新一次最高频率
watch -n 0.5 "grep 'cpu MHz' /proc/cpuinfo | sort -n | tail -1"

观察结果
- 最初可能看到较高频率（接近2.4GHz）
- 持续几分钟后，频率会下降到2000MHz附近
- 这是因为云平台的CPU信用用尽

为什么设计成这样的限制？

公平资源分配
- 保证每个用户至少获得2000MHz
- 允许短期突发提升性能
防止邻居干扰
- 避免某个虚拟机独占物理CPU资源
计费模型
- 基础频率对应基础费用
- 突发频率可能产生额外费用

性能建议

检查CPU配额

# 对于KVM虚拟机
sudo virsh vcpuinfo $(hostname)

# 检查CPU节流
grep -E 'cpu_throttle' /proc/*/status

监控CPU信用（如果是AWS EC2风格）

# 安装云监控工具
sudo apt install amazon-cloudwatch-agent -y

# 查看CPU积分余额
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status