1. 为什么用圆周率计算来做CPU压力测试

1.1 一个看似“无用”却极其精准的测试思路

很多人第一次听到“用圆周率计算来压CPU”的时候，反应都是：这玩意儿能测出什么？跑个分不就行了？但真正在运维和硬件测试一线待过的人都知道，跑分软件测的是“峰值性能”，而压力测试要的是“持续满载下的稳定性”。这两件事完全不是一回事。

圆周率计算恰好具备几个非常适合做压力测试的特质。第一，它是纯计算密集型任务，几乎不涉及磁盘IO和网络IO，能把压力精准地压在CPU的算术逻辑单元上。第二，它的计算过程可以无限迭代，你想压多久就压多久，不存在“跑完了没压满”的尴尬。第三，它的算法可以自由调节精度和迭代次数，也就是说压力的“强度”是可以量化的、可调的。第四，Python虽然本身执行效率不高，但正因为如此，它反而能制造出非常稳定的高负载——CPU几乎一直在做浮点运算和循环控制，不会出现忽高忽低的波动。

我最早接触这个思路，是在给一批二手服务器做稳定性筛选的时候。那批机器来源杂，有的跑分很好看，但连续跑几个小时高负载就蓝屏或者降频。后来我用Python写了一个圆周率计算的脚本，让每台机器连续跑8小时，结果一下子筛出了三台有散热问题的机器。从那以后，这个看起来“简陋”的方法就成了我工具箱里的常备手段。

1.2 这个方案适合谁，能解决什么问题

这个方案适合的人群其实比想象中广。如果你是运维工程师，需要批量测试新到货的服务器或者云主机；如果你是硬件爱好者，想验证自己超频后的机器是否稳定；如果你是开发者，想测试多线程程序在满载情况下的表现；甚至如果你只是想知道自己笔记本的散热到底行不行，这个方案都能用。

它能解决的问题也很明确：第一，验证CPU在持续满载下是否会降频、死机或报错；第二，对比不同机器或不同散热条件下的性能差异；第三，作为多线程编程的练手项目，理解GIL（全局解释器锁）对CPU密集型任务的影响；第四，在没有专业测试工具的环境下，快速搭建一个可定制的压力测试环境。

需要提前说明的是，这个方案不会告诉你CPU的具体型号参数，也不会给你一个“跑分”，它给你的是一段时间内CPU的“工作状态记录”。你要关注的是：计算速度是否稳定、温度是否可控、有没有出现计算错误。这些信息对于判断一台机器是否“靠谱”，比一个孤零零的分数有用得多。

2. 核心原理拆解：圆周率计算为什么能压住CPU

2.1 从数学公式到CPU负载的转化逻辑

圆周率的计算方法有很多种，但适合做压力测试的，必须满足两个条件：计算过程要足够“重”，且每一步都依赖前一步的结果，这样才能让CPU一直处于忙碌状态。目前常用的有三种方法，我分别说一下它们的特性和适用场景。

第一种是莱布尼茨级数，公式是 π/4 = 1 - 1/3 + 1/5 - 1/7 + ...。这个公式极其简单，收敛速度慢得令人发指，但正因为慢，它非常适合做长时间压力测试。你只要设定一个很大的迭代次数，CPU就会一直做除法、加法和减法。它的优点是代码简单、不容易出错，缺点是精度提升太慢，跑半天也就算出几位小数。

第二种是蒙特卡洛方法，在一个正方形里随机撒点，统计落在内切圆里的比例来估算π。这个方法涉及大量随机数生成和浮点运算，对CPU的浮点单元压力很大。但它的缺点是结果有随机性，每次跑出来的精度不一样，不太适合做“可复现”的测试。

第三种是Chudnovsky算法或者Machin公式，这些是高精度计算π的常用方法，收敛速度极快，但实现复杂，涉及大数运算。用它们做压力测试，CPU的负载模式会偏向整数运算和内存访问，和纯浮点压力测试的侧重点不同。

我个人的选择是：用莱布尼茨级数做长时间稳定性测试，用蒙特卡洛方法做短时间高强度的浮点压力测试。这两种方法配合使用，基本能覆盖大部分场景。

2.2 Python的GIL对压力测试的影响

这里必须专门讲一下Python的GIL问题，因为很多人写多线程压力测试脚本时会踩这个坑。GIL（全局解释器锁）的存在，使得同一时刻只有一个线程能执行Python字节码。这意味着，如果你用多线程跑圆周率计算，CPU的多个核心并不会同时满载——实际上只有一个核心在真正干活，其他核心都在等锁。

我实测过，在一个4核8线程的机器上，用4个线程跑莱布尼茨级数，CPU总占用率只有25%左右，也就是只有一个核心跑满了。这显然达不到压力测试的目的。

解决方案有两个：一是用多进程代替多线程，每个进程有独立的Python解释器和GIL，可以真正并行；二是用C扩展或者NumPy这类底层释放GIL的库来执行计算。对于压力测试来说，多进程是最简单直接的选择，因为我们的目的就是让CPU满载，而不是追求计算效率。

注意：如果你用多进程，每个进程都会占用一份内存，所以进程数不要超过物理核心数太多，否则会开始吃交换分区，反而影响测试结果。

2.3 压力强度的量化：迭代次数与时间的关系

做压力测试，最怕的就是“凭感觉”。我们需要一个可量化的指标，来知道当前的负载到底有多重。对于莱布尼茨级数来说，迭代次数就是最直接的量化指标。

我做过一组实测数据，在一台搭载某型号4核CPU的机器上，单进程Python跑莱布尼茨级数，每秒钟大约能完成800万到1200万次迭代（具体取决于CPU频率和Python版本）。这个数字可以作为基准，用来估算你需要设置多大的迭代次数。

比如你想让单个核心满载运行10分钟，那就是600秒，按每秒1000万次迭代算，大约需要60亿次迭代。这个数字看起来很大，但在Python里就是一个整数参数而已。你可以把这个参数做成命令行输入，方便调整测试时长。

更精确的做法是：先跑一个短时间的基准测试（比如10秒），记录实际完成的迭代次数，然后根据目标时长按比例放大。这样即使在不同机器上，也能保证测试时长的一致性。

3. 动手实现：从单进程到多进程的完整脚本

3.1 单进程版本：先跑通最基本的逻辑

我们先从最简单的单进程版本开始，把核心逻辑跑通，再逐步加功能。这个版本的目标是：给定一个迭代次数，计算π的近似值，并输出耗时和计算结果。

import time import sys def calculate_pi_leibniz(iterations): """ 使用莱布尼茨级数计算圆周率 iterations: 迭代次数，越大越精确，CPU负载越重 """ pi_approx = 0.0 sign = 1.0 denominator = 1.0 for i in range(iterations): pi_approx += sign / denominator sign = -sign denominator += 2.0 return pi_approx * 4.0 def main(): # 默认迭代1亿次，大约需要10-20秒 iterations = int(sys.argv[1]) if len(sys.argv) > 1 else 100_000_000 print(f"开始计算，迭代次数: {iterations:,}") start_time = time.time() pi_value = calculate_pi_leibniz(iterations) elapsed = time.time() - start_time print(f"计算完成，耗时: {elapsed:.2f} 秒") print(f"π的近似值: {pi_value:.15f}") print(f"每秒迭代次数: {iterations / elapsed:,.0f}") if __name__ == "__main__": main()

这段代码有几个细节值得说明。第一，我用sign和denominator两个变量来交替加减，而不是用(-1)**i，因为幂运算在Python里比简单的符号翻转慢很多。第二，我用了100_000_000这种下划线分隔的写法，纯粹是为了可读性，Python 3.6以上都支持。第三，输出里包含了“每秒迭代次数”，这个指标比单纯的耗时更有参考价值，因为它排除了迭代次数不同的干扰。

跑一下这个脚本，你会看到CPU占用率直接飙到25%左右（在4核机器上），因为只有一个核心在干活。这就是单进程的局限，但也是我们理解多进程的基础。

3.2 多进程版本：让所有核心都跑起来

单进程版本跑通之后，多进程版本就水到渠成了。核心思路是：用multiprocessing模块创建多个进程，每个进程跑相同或不同的迭代次数，最后汇总结果。

import time import sys import multiprocessing import os def calculate_pi_leibniz(iterations): """莱布尼茨级数计算圆周率，返回(π值, 耗时)""" pi_approx = 0.0 sign = 1.0 denominator = 1.0 start = time.time() for i in range(iterations): pi_approx += sign / denominator sign = -sign denominator += 2.0 elapsed = time.time() - start return pi_approx * 4.0, elapsed def worker(args): """每个进程执行的函数""" process_id, iterations = args pid = os.getpid() print(f"[进程 {process_id}] PID={pid} 启动，迭代次数: {iterations:,}") pi_value, elapsed = calculate_pi_leibniz(iterations) print(f"[进程 {process_id}] PID={pid} 完成，耗时: {elapsed:.2f}秒，π≈{pi_value:.10f}") return process_id, elapsed, pi_value def main(): # 默认使用所有CPU核心 cpu_count = multiprocessing.cpu_count() process_count = int(sys.argv[1]) if len(sys.argv) > 1 else cpu_count iterations_per_process = int(sys.argv[2]) if len(sys.argv) > 2 else 50_000_000 print(f"CPU核心数: {cpu_count}") print(f"启动进程数: {process_count}") print(f"每进程迭代次数: {iterations_per_process:,}") print("-" * 50) # 准备参数 tasks = [(i, iterations_per_process) for i in range(process_count)] start_time = time.time() # 创建进程池并执行 with multiprocessing.Pool(processes=process_count) as pool: results = pool.map(worker, tasks) total_elapsed = time.time() - start_time print("-" * 50) print(f"全部完成，总耗时: {total_elapsed:.2f}秒") # 统计信息 avg_elapsed = sum(r[1] for r in results) / len(results) print(f"平均单进程耗时: {avg_elapsed:.2f}秒") print(f"总迭代次数: {process_count * iterations_per_process:,}") print(f"整体每秒迭代次数: {process_count * iterations_per_process / total_elapsed:,.0f}") if __name__ == "__main__": main()

这个版本有几个关键点需要解释。第一，multiprocessing.Pool会自动管理进程的创建和回收，比手动Process更省心。第二，pool.map会把任务列表分发给各个进程，每个进程独立执行worker函数。第三，每个进程的elapsed是独立计算的，而total_elapsed是墙钟时间，两者的差异能反映出进程间的资源竞争情况。

实测下来，在4核机器上跑4个进程，CPU占用率能稳定在95%以上，所有核心都跑满了。这时候你摸一下机器出风口，能明显感觉到热浪——这才是真正的压力测试。

3.3 参数调优：迭代次数、进程数与测试时长的关系

多进程版本跑起来之后，下一个问题就是：参数怎么设？这里我给出一个实用的调参流程。

第一步，先确定测试时长。你是想跑5分钟快速验证，还是跑8小时做稳定性筛选？这个决定了总迭代次数。

第二步，跑一个基准测试。用单进程跑1000万次迭代，记录耗时。假设耗时是1.2秒，那么每秒迭代次数就是约833万次。

第三步，计算每进程迭代次数。如果你要跑10分钟（600秒），4个进程，那么每进程需要跑600秒，即600 × 833万 ≈ 50亿次迭代。这个数字就是你要设置的iterations_per_process。

第四步，留出余量。实际跑的时候，由于多进程竞争内存带宽和缓存，单进程速度可能会下降10%到20%。所以你可以把迭代次数再乘以1.2，确保测试时长足够。

下面这个表格是我在一台4核机器上实测的数据，供你参考：

从表里能看出两个规律：第一，进程数从1增加到4，总耗时只增加了20%，但总计算量翻了4倍，说明多进程确实在并行干活。第二，进程数超过物理核心数（4核跑8进程）之后，总耗时几乎翻倍，这是因为操作系统在频繁切换进程上下文，反而降低了效率。所以进程数不要超过物理核心数，这是铁律。

4. 测试过程中的监控与数据记录

4.1 怎么在测试时看CPU温度和频率

光跑脚本不看监控，等于白跑。压力测试的核心价值在于“观察”，你得知道CPU在满载时的真实状态。不同操作系统下，监控手段不一样，我分别说一下。

在Linux环境下，最直接的工具是top和sensors。top按1可以展开每个核心的占用率，按P按CPU排序。sensors需要先安装lm-sensors包，然后运行sensors-detect配置，之后直接敲sensors就能看到每个核心的温度和风扇转速。我通常会把sensors的输出重定向到一个日志文件，每隔几秒记录一次，测试结束后画成曲线。

在Windows环境下，可以用任务管理器的“性能”标签页看CPU占用和频率，但温度需要第三方工具。我常用的是HWiNFO，它能记录CPU温度、频率、功耗等几十项指标，并且支持导出CSV。跑测试的时候开着它，测试结束后把CSV拖进Excel，一目了然。

在macOS环境下，sudo powermetrics能看到CPU频率和功耗，但温度需要istats或者TG Pro这类工具。不过Mac的散热设计通常比较保守，压力测试时降频会比较明显，这一点要有心理预期。

提示：不管用什么工具，建议在测试开始前先记录5分钟的“空闲状态”数据作为基线，这样对比起来才有意义。否则你看到CPU温度80度，也不知道是本来就高还是压力测试导致的。

4.2 记录哪些数据才有分析价值

跑一次压力测试，至少要记录以下几类数据，否则测试结果没有参考价值。

第一类是时间戳，精确到秒就行。这是所有数据的基础，用来对齐不同来源的记录。

第二类是CPU占用率，包括总体占用率和每个核心的占用率。总体占用率反映负载是否均匀，单核心占用率能看出是否有“偷懒”的核心。

第三类是CPU频率。这是判断是否降频的关键指标。如果频率从标称的3.5GHz掉到了2.0GHz，说明散热跟不上，机器在自我保护。

第四类是CPU温度。这个不用多说，温度过高会导致降频甚至关机。

第五类是计算进度。也就是每秒迭代次数，或者每完成多少迭代记录一次时间。这个数据能反映计算速度是否稳定，如果中途突然变慢，可能是遇到了内存交换或者温度墙。

我通常会把这几类数据合并到一个CSV文件里，格式大概是：timestamp, cpu_percent, cpu_freq_mhz, cpu_temp_c, iterations_per_sec。测试结束后用Python的pandas或者直接Excel画图，一眼就能看出问题。

4.3 一个实用的监控脚本模板

为了省事，我写了一个简单的监控脚本，在Linux下用psutil库采集数据，每5秒记录一次。这个脚本可以独立运行，也可以和压力测试脚本一起启动。

import psutil import time import csv from datetime import datetime def monitor_cpu(duration_seconds, interval=5, output_file="cpu_monitor.csv"): """ 监控CPU状态并记录到CSV文件 duration_seconds: 监控总时长 interval: 采样间隔（秒） output_file: 输出文件名 """ end_time = time.time() + duration_seconds with open(output_file, 'w', newline='') as f: writer = csv.writer(f) writer.writerow(['timestamp', 'cpu_percent', 'cpu_freq_mhz', 'per_cpu_percent']) while time.time() < end_time: timestamp = datetime.now().strftime('%Y-%m-%d %H:%M:%S') cpu_percent = psutil.cpu_percent(interval=1) # 获取CPU频率（部分系统可能不支持） try: freq = psutil.cpu_freq() cpu_freq = freq.current if freq else 0 except Exception: cpu_freq = 0 # 每个核心的占用率 per_cpu = psutil.cpu_percent(percpu=True) writer.writerow([timestamp, cpu_percent, cpu_freq, per_cpu]) f.flush() # 等待到下一个采样点 time.sleep(max(0, interval - 1)) print(f"监控数据已保存到 {output_file}") if __name__ == "__main__": import sys duration = int(sys.argv[1]) if len(sys.argv) > 1 else 300 monitor_cpu(duration)

这个脚本依赖psutil库，安装命令是pip install psutil。它每5秒采集一次数据，包括总体占用率、频率和每个核心的占用率。跑完之后，你可以用Excel打开CSV，插入折线图，CPU的“工作状态”就一目了然了。

需要注意的是，psutil.cpu_freq()在部分虚拟机和容器环境下会返回None，这时候频率就记录为0。如果你是在云主机上测试，频率数据可能拿不到，那就重点关注占用率和计算速度的变化。

5. 常见问题与排查技巧实录

5.1 为什么CPU占用率上不去

这是最常见的问题。你明明开了4个进程，但任务管理器里CPU占用率只有30%到40%。原因通常有以下几个。

第一个原因是进程数不够。如果你只开了1个进程，那在4核机器上占用率就是25%左右，这是正常的。解决办法是增加进程数，但不要超过物理核心数。

第二个原因是Python版本问题。Python 3.12之前的版本，GIL的释放策略比较保守，某些情况下即使多进程也会出现“一个进程干活，其他进程围观”的现象。我实测过，Python 3.12在多进程CPU密集型任务上的表现比3.10好不少。如果你有条件，建议用3.12或更高版本。

第三个原因是计算任务太轻。如果你设置的迭代次数太少，进程很快就跑完了，CPU还没来得及满载就结束了。解决办法是增加迭代次数，让每个进程至少跑30秒以上。

第四个原因是系统电源管理策略。有些笔记本在电池模式下会限制CPU性能，即使你插着电，电源计划也可能设置为“节能”。在Windows下，把电源计划改成“高性能”；在Linux下，用cpupower frequency-set -g performance把调频策略设为性能模式。

5.2 计算速度突然变慢是怎么回事

测试过程中，如果发现每秒迭代次数突然下降，通常有以下几种可能。

第一种可能是温度墙。CPU温度达到阈值（通常是95度或100度）后，会自动降频来保护自己。这时候你会看到频率下降、计算速度变慢。解决办法是改善散热，比如清理风扇灰尘、更换硅脂、增加机箱风扇。

第二种可能是内存交换。如果你开的进程太多，或者迭代次数设置得太大，导致内存不够用，系统会开始使用交换分区。交换分区的读写速度比内存慢几个数量级，计算速度会断崖式下跌。解决办法是减少进程数，或者增加物理内存。

第三种可能是其他程序抢资源。测试的时候最好关掉浏览器、聊天软件、自动更新等后台程序。我踩过一次坑，Windows在后台偷偷下载更新，导致测试结果完全不可用。

第四种可能是CPU降频策略。有些CPU在持续高负载下会主动降低频率来省电，这叫“功耗墙”。这种情况在轻薄本上特别常见，解决办法是接受现实，或者换一台散热更好的机器。

5.3 多进程脚本报错怎么排查

多进程脚本比单进程脚本更容易出问题，常见的报错和解决办法我整理成了下面这个表格。

其中最容易踩的是Windows下的pickle问题。在Linux和macOS上，多进程默认用fork方式创建，子进程直接继承父进程的内存空间，不需要序列化。但在Windows上，只能用spawn方式，子进程需要重新导入模块，所以worker函数必须定义在模块顶层，不能是嵌套函数或lambda。这个坑我踩过不止一次，每次换到Windows环境都要重新提醒自己。

5.4 测试结果怎么解读

跑完测试，拿到数据，下一步就是解读。我通常关注三个指标：稳定性、散热能力和性能一致性。

稳定性看的是计算速度的波动。如果每秒迭代次数在测试过程中基本平稳，波动不超过5%，说明机器很稳。如果波动超过20%，或者中途出现断崖式下跌，说明有问题。

散热能力看的是温度和频率的关系。如果温度稳定在80度以下，频率保持在标称值附近，说明散热合格。如果温度冲到95度以上，频率掉到标称值的60%以下，说明散热需要改进。

性能一致性看的是多进程之间的差异。如果4个进程的耗时相差不超过10%，说明核心之间的性能比较均衡。如果某个进程明显慢很多，可能是那个核心有体质问题，或者被其他任务干扰了。

我一般会把测试结果分成三档：优秀（速度稳定、温度低于80度、无降频）、合格（速度基本稳定、温度80到90度、轻微降频）、不合格（速度波动大、温度超过90度、明显降频）。这个标准不是绝对的，但能快速给出一个判断。

6. 进阶玩法：让压力测试更贴近真实场景

6.1 混合负载测试：CPU加内存一起压

纯CPU压力测试只能测出CPU的稳定性，但真实场景下，CPU往往和内存一起工作。如果你想做更全面的测试，可以在圆周率计算的同时，加入内存读写操作。

一个简单的做法是：在每次迭代中，除了做浮点运算，还往一个预分配的列表里写入数据。这样CPU既要算，又要访问内存，负载模式更接近真实应用。

def calculate_pi_with_memory_pressure(iterations, memory_buffer_size=10000): """带内存压力的圆周率计算""" pi_approx = 0.0 sign = 1.0 denominator = 1.0 # 预分配内存缓冲区 buffer = [0.0] * memory_buffer_size buffer_index = 0 for i in range(iterations): pi_approx += sign / denominator sign = -sign denominator += 2.0 # 每1000次迭代写一次内存 if i % 1000 == 0: buffer[buffer_index] = pi_approx buffer_index = (buffer_index + 1) % memory_buffer_size return pi_approx * 4.0

这个版本的计算速度会比纯计算慢一些，但CPU和内存的负载都上去了。你可以通过调整memory_buffer_size来控制内存压力的大小。缓冲区越大，内存访问越分散，对缓存的压力越大。

6.2 定时启停：模拟间歇性高负载

有些场景下，CPU不是一直满载，而是间歇性高负载。比如Web服务器在高峰期处理请求，闲时几乎空闲。要模拟这种场景，可以写一个定时启停的脚本。

import time import multiprocessing import random def burst_worker(burst_duration, idle_duration, total_duration): """间歇性压力测试：忙一阵，歇一阵""" end_time = time.time() + total_duration while time.time() < end_time: # 忙阶段 busy_end = time.time() + burst_duration while time.time() < busy_end: # 执行一段计算 _ = sum(i * i for i in range(10000)) # 歇阶段 time.sleep(idle_duration) def main(): process_count = multiprocessing.cpu_count() total_duration = 300 # 总共跑5分钟 processes = [] for i in range(process_count): # 每个进程的忙闲节奏略有不同，更接近真实场景 burst = random.uniform(2, 5) idle = random.uniform(1, 3) p = multiprocessing.Process( target=burst_worker, args=(burst, idle, total_duration) ) processes.append(p) p.start() for p in processes: p.join() print("间歇性压力测试完成") if __name__ == "__main__": main()

这个脚本会让每个进程随机地忙一阵、歇一阵，整体CPU占用率会在60%到100%之间波动。这种模式对电源管理和散热系统的考验更大，因为CPU需要频繁地升降频。

6.3 结果可视化：用图表说话

数据记录下来了，但一堆CSV数字看起来太累。我通常会用matplotlib画几张图，直观地展示测试结果。

import pandas as pd import matplotlib.pyplot as plt def plot_cpu_monitor(csv_file): """绘制CPU监控数据图表""" df = pd.read_csv(csv_file) df['timestamp'] = pd.to_datetime(df['timestamp']) fig, axes = plt.subplots(3, 1, figsize=(12, 8), sharex=True) # 图1：CPU占用率 axes[0].plot(df['timestamp'], df['cpu_percent'], color='blue') axes[0].set_ylabel('CPU占用率 (%)') axes[0].set_title('CPU压力测试监控数据') axes[0].grid(True, alpha=0.3) # 图2：CPU频率 axes[1].plot(df['timestamp'], df['cpu_freq_mhz'], color='green') axes[1].set_ylabel('CPU频率 (MHz)') axes[1].grid(True, alpha=0.3) # 图3：每个核心的占用率（取第一个核心作为示例） # 注意：per_cpu字段是列表字符串，需要解析 # 这里简化处理，实际使用时需要根据CSV格式调整 axes[2].set_ylabel('单核心占用率 (%)') axes[2].set_xlabel('时间') axes[2].grid(True, alpha=0.3) plt.tight_layout() plt.savefig('cpu_test_result.png', dpi=150) plt.show() if __name__ == "__main__": plot_cpu_monitor("cpu_monitor.csv")

这张图能让你一眼看出：CPU占用率是否稳定、频率是否下降、温度是否过高。如果频率曲线在某个时间点突然下跌，而温度曲线同时冲高，那就是典型的温度墙。如果频率一直很低，但温度也不高，那可能是电源策略限制了性能。

我个人在实际操作中的体会是，压力测试的价值不在于“跑出一个分数”，而在于“发现异常”。一台机器跑分高不高，其实没那么重要；重要的是它在持续高负载下会不会出问题。圆周率计算这个方案，胜在简单、可控、可复现，不需要安装任何专业软件，一个Python脚本就能搞定。你可以在任何有Python环境的机器上跑，也可以根据需要调整压力强度和测试时长。对于日常的稳定性验证来说，这套方法足够用了。

最后再分享一个小技巧：如果你要测试多台机器，可以把脚本和监控工具打包成一个压缩包，写一个一键启动的批处理或shell脚本，这样批量测试的时候能省不少事。测试结果统一保存到以机器编号命名的文件夹里，方便后续对比分析。