在将业务迁移到Hetzner云服务器之前，很多团队只做过短暂的基准测试，比如跑几分钟sysbench或者Geekbench，看到分数不错就认为性能达标。但实际生产环境中，CPU可能需要连续数天甚至数周处于高负载状态，比如视频转码、科学计算、持续集成任务。短期测试无法暴露长期满载时可能出现的频率下降、性能波动甚至意外重启等问题。本文将以一次真实的72小时CPU满负载测试为例，介绍如何系统性地评估Hetzner云服务器的CPU长期稳定性，并给出可复用的测试脚本和结果分析思路。
为什么需要长期CPU负载测试
短期基准测试通常只关注CPU在几秒或几分钟内的瞬时性能，而长期负载测试的核心在于观察持续压力下的行为变化。云服务器与物理服务器最大的不同在于虚拟化层和资源调度策略。Hetzner的共享vCPU实例（如CX系列）允许多个虚拟机共享同一物理核心，当邻居虚拟机突然产生高负载时，你的实例可能会被限制CPU时间片，导致有效性能下降。这种现象在短期测试中几乎不会出现，但持续负载下会周期性复现。
另一个关键问题是热降频。无论是物理机还是虚拟机，CPU温度过高都会触发保护机制降低频率。在云环境中，宿主机散热条件通常较好，但如果你的实例被调度到散热不佳的物理节点，或者长时间满载导致散热系统老化，就可能出现频率从标称值（比如3.8GHz）降低到2.5GHz的情况。这种降频在短期测试中可能只有短暂出现，而长期测试可以捕捉到降频发生的频率和持续时间。
此外，长期测试还能暴露虚拟化平台本身的稳定性问题，例如CPU指令执行错误、虚拟中断丢失导致的软锁死，或者内核在持续压力下出现内存泄漏。这些问题一旦发生，轻则影响任务完成时间，重则导致服务中断。通过监控日志和系统状态，可以提前发现潜在隐患。
测试环境与工具选择
本次测试使用了Hetzner的两类实例进行对比：一台CX21（2 vCPU，共享核心，4GB内存）和一台CPX21（2 vCPU，专用核心，4GB内存）。操作系统统一安装Ubuntu 22.04 LTS，内核版本5.15。选择Ubuntu是因为其软件仓库中的压力测试工具版本较新，且系统监控工具齐全。
压力测试工具选用stress-ng和sysbench。前者功能丰富，可以模拟多种CPU负载模式（整数运算、浮点运算、缓存压力等），适合长时间跑混合负载；后者主要用于对比短时性能分数。安装命令如下：
sudo apt update sudo apt install -y stress-ng sysbench htop lm-sensors cpufrequtils
监控数据采集使用自定义Shell脚本，定期读取/proc/stat获取CPU总使用率，读取/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq获取当前频率，使用sensors命令获取核心温度。脚本将结果追加写入CSV文件，便于后续分析。同时启用sar（需要安装sysstat包）记录系统级别的CPU统计数据，作为交叉验证。
设计并执行72小时负载测试
测试方案分为两个阶段：前24小时施加全核100%的整数计算负载，模拟典型的CPU密集型任务；后48小时改为70%静态负载+30%随机波动负载，更接近真实生产环境的混合型工作负载。使用stress-ng的命令如下：
# 全核满载，持续24小时 stress-ng --cpu 2 --cpu-method int64 --timeout 24h --verbose # 混合负载：70%基础负载 + 每5分钟随机增加一个worker，持续48小时 stress-ng --cpu 2 --cpu-method matrixprod --cpu-load 70 --timeout 48h & while true; do sleep 300 load=$(shuf -i 1-3 -n 1) stress-ng --cpu $load --cpu-method fft --timeout 60s & done
监控脚本每30秒采样一次，核心代码如下：
#!/bin/bash
OUTPUT="/var/log/cpu_monitor.csv"
echo "timestamp,cpu_usage,core0_freq,core1_freq,temp0,temp1" > $OUTPUT
while true; do
# 获取CPU总使用率（基于/proc/stat两次采样的差值）
cpu_line=$(grep '^cpu ' /proc/stat)
idle1=$(echo $cpu_line | awk '{print $5}')
total1=$(echo $cpu_line | awk '{print $2+$3+$4+$5+$6+$7+$8}')
sleep 1
cpu_line=$(grep '^cpu ' /proc/stat)
idle2=$(echo $cpu_line | awk '{print $5}')
total2=$(echo $cpu_line | awk '{print $2+$3+$4+$5+$6+$7+$8}')
usage=$(echo "scale=2; 100 * (1 - ($idle2 - $idle1) / ($total2 - $total1))" | bc)
# 读取每个核心的当前频率（单位kHz，转换为MHz）
freq0=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq)
freq1=$(cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq)
freq0_mhz=$((freq0 / 1000))
freq1_mhz=$((freq1 / 1000))
# 温度信息（如果有传感器）
temp0=$(sensors | grep 'Core 0' | awk '{print $3}' | tr -d '+°C')
temp1=$(sensors | grep 'Core 1' | awk '{print $3}' | tr -d '+°C')
ts=$(date +%Y-%m-%dT%H:%M:%S)
echo "$ts,$usage,$freq0_mhz,$freq1_mhz,$temp0,$temp1" >> $OUTPUT
sleep 30
done
以上脚本在后台运行，日志文件会持续增长。72小时后停止压力测试，将CSV文件下载到本地使用Python或Excel进行分析。
结果分析与调优建议
测试结束后，对比两台实例的数据可以发现明显差异。CX21（共享vCPU）在测试开始的前6小时内频率保持在3.6GHz左右，但从第7小时开始频繁出现频率下跌至2.2GHz并持续数分钟的现象，同时CPU使用率虽然保持100%，但系统负载（load average）从2.0上升至4.5，说明vCPU被宿主机限流。这种波动在夜间和白天均有出现，频率大约每小时2-3次，每次持续1-5分钟。CPX21（专用vCPU）则在72小时内频率始终稳定在3.8GHz，温度稳定在65-72摄氏度之间，没有出现任何降频或性能波动。
进一步分析CSV数据可以发现，共享实例的频率波动与邻居虚拟机的活动高度相关，因为无法从客户机内部直接看到宿主机调度情况，但通过对比同一时刻的系统日志和外部监控（如Ping延迟），可以推断出存在资源竞争。这类波动对于延迟敏感型应用（如实时视频处理、在线游戏服务）可能造成明显卡顿。
基于以上结果，给出以下建议：第一，对于需要长期稳定CPU性能的生产环境，优先选择专用vCPU实例（如Hetzner的CPX系列），虽然价格略高，但避免了邻居干扰带来的不确定性。第二，如果必须使用共享实例，应设置性能告警，例如当CPU频率持续低于标称值的80%超过10分钟时触发通知。第三，可以在应用层实现弹性降级策略，当检测到CPU性能下降时自动降低任务并发度或切换至备用节点。第四，定期执行长期负载测试，监控宿主机硬件老化或虚拟化平台更新带来的性能变化。
最后需要提醒的是，CPU长期负载测试只是云服务器评估的一部分，还应结合内存、磁盘I/O和网络稳定性进行综合测试。但通过本文介绍的这套方法，你可以对Hetzner云服务器的CPU长期表现有一个量化的认识，从而做出更合理的架构决策。
Hetzner云服务器CPU负载测试长期稳定性修改时间：2026-08-30 14:51:21