Python多进程圆周率计算：轻量级CPU压力测试与性能监控实战

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

1.1 一个看似简单却暗藏玄机的选择

很多人第一次听到“用Python算圆周率来压CPU”这个想法时，反应大概是：这能行吗？Python那么慢，算个圆周率能有多大压力？但恰恰是这种“慢”，让它成为一个非常理想的压力测试载体。你想想看，CPU压力测试的核心诉求是什么？是让CPU尽可能长时间地处于高负载状态，同时能够量化地观察它的表现——温度、频率、稳定性、多核调度能力。而圆周率计算，尤其是使用高精度算法（比如Chudnovsky算法或Machin公式），天然具备几个关键特性：计算密集、可调精度、结果可验证、纯计算无IO。

我最早接触这个思路是在一次老旧笔记本的散热改造之后。当时手头没有现成的压力测试工具，又不想装一堆重型软件，就想着用Python写一个轻量的、能跑满所有核心的测试脚本。试过死循环、试过递归斐波那契，最后发现圆周率计算是最“优雅”的方案——因为它有明确的计算目标，你能看到进度，能验证结果，还能通过调整小数位数来精确控制测试时长。

1.2 圆周率计算压测的独特优势

相比传统的压力测试工具（比如Prime95、AIDA64），自己用Python写圆周率压测有几个不可替代的好处。第一是完全透明可控，你知道每一行代码在干什么，不会出现“黑箱”式的负载。第二是跨平台无依赖，只要装了Python，Windows、macOS、Linux甚至树莓派上都能跑，不需要编译安装。第三是可定制性强，你可以轻松改成多进程、多线程，或者加入温度监控、频率记录等扩展功能。

当然，它也有局限性。Python的GIL（全局解释器锁）意味着单进程多线程无法真正利用多核，所以必须用多进程方案。另外，纯Python的圆周率计算速度远不如C语言实现，但这反而成了优点——你不需要跑太久就能让CPU达到满载，测试门槛更低。

注意：如果你的目标是测试CPU的极限稳定性（比如超频后的验证），建议用专门的工具跑长时间测试。Python方案更适合快速验证散热能力、观察多核调度行为，或者作为教学演示。

1.3 适合哪些人参考这个方案

这个项目特别适合几类人：一是硬件爱好者，想快速测试新装散热器或硅脂的效果；二是Python学习者，想通过一个实际项目理解多进程、算法优化和性能监控；三是运维或测试人员，需要在不同机器上快速部署一个轻量级负载生成器。哪怕你只是好奇自己的笔记本在满载时会不会降频，这个脚本也能给你直观的答案。

2. 核心算法选型与性能考量

2.1 为什么选Chudnovsky算法而不是蒙特卡洛

圆周率的计算方法很多，从简单的莱布尼茨级数到复杂的Chudnovsky算法，性能差异巨大。莱布尼茨级数（π/4 = 1 - 1/3 + 1/5 - 1/7 + ...）虽然代码极简，但收敛速度慢得令人发指——要算到小数点后10位都需要数百万次迭代。蒙特卡洛方法用随机撒点来估算π，代码有趣但精度提升极慢，而且依赖随机数生成器，结果不稳定。

Chudnovsky算法是目前已知收敛最快的圆周率算法之一，每计算一项就能获得约14位精确数字。它的核心公式涉及阶乘和幂运算，计算量大但收敛极快。用Python实现时，配合decimal模块的高精度运算，可以在几秒内算出几千位π值。这种“计算量大但结果精确”的特性，正是压力测试需要的——CPU会持续处于高负载状态，同时你还能验证计算结果的正确性。

from decimal import Decimal, getcontext def chudnovsky(n): getcontext().prec = n + 10 C = 426880 * Decimal(10005).sqrt() M = 1 L = 13591409 X = 1 K = 6 S = Decimal(L) for i in range(1, n // 14 + 2): M = M * (K**3 - 16*K) // (i**3) L += 545140134 X *= -262537412640768000 S += Decimal(M * L) / X K += 12 pi = C / S return pi

上面这段代码就是Chudnovsky算法的Python实现。注意几个关键点：getcontext().prec设置精度时要多留10位余量，因为计算过程中会有舍入误差；循环次数用n // 14 + 2估算，因为每项贡献约14位精度；所有大数运算都用Decimal类型，避免浮点溢出。

2.2 精度与计算时长的关系实测

为了让你对计算量有个直观感受，我在一台搭载四核处理器的旧笔记本上做了实测。测试环境是Python 3.11，单进程运行，结果如下：

可以看到，单进程只能利用一个核心，CPU占用率始终在25%左右（四核八线程的话就是12.5%）。要让所有核心都跑起来，必须用多进程方案。另外，计算耗时随精度增长呈超线性关系——精度翻倍，耗时可能增加2.5倍以上，因为大数乘法的复杂度不是线性的。

实操心得：如果你只是想快速让CPU热起来，10000位精度跑多进程就足够了。如果要做长时间稳定性测试，建议用50000位以上，配合循环执行。

2.3 多进程方案的设计思路

Python的multiprocessing模块是绕开GIL限制的标准方案。核心思路很简单：启动N个进程（N等于CPU逻辑核心数），每个进程独立计算圆周率，互不干扰。但有几个细节需要注意。

第一，进程启动方式。Windows上默认用spawn，Linux上默认用fork。spawn会重新导入模块，所以所有代码必须放在if __name__ == '__main__':保护块内，否则会无限递归创建进程。第二，结果收集。如果每个进程都返回巨大的π值字符串，进程间通信会成为瓶颈。建议只返回计算耗时和π的前几位用于验证，完整结果可以丢弃或写入文件。第三，优雅退出。压力测试通常需要跑一段时间后手动停止，要处理好KeyboardInterrupt，确保所有子进程都能被正确终止。

import multiprocessing import time from decimal import Decimal, getcontext def worker(precision, result_queue): start = time.time() pi = chudnovsky(precision) elapsed = time.time() - start result_queue.put((precision, elapsed, str(pi)[:20])) if __name__ == '__main__': cpu_count = multiprocessing.cpu_count() queue = multiprocessing.Queue() processes = [] for _ in range(cpu_count): p = multiprocessing.Process(target=worker, args=(10000, queue)) p.start() processes.append(p) for p in processes: p.join() while not queue.empty(): print(queue.get())

这段代码会启动与CPU核心数相同的进程，每个进程计算10000位π。实测在四核机器上，CPU占用率能稳定在95%以上。

3. 完整压测脚本的搭建与实操

3.1 环境准备与依赖说明

这个项目对环境的依赖极低，只需要Python 3.6以上版本，标准库中的multiprocessing、decimal、time、argparse就足够了。不需要安装任何第三方包，这也是我特别喜欢这个方案的原因——在任何一台能跑Python的机器上，复制粘贴就能用。

如果你想要更丰富的监控功能，可以选装psutil库来获取CPU温度和频率（需要操作系统支持），或者用matplotlib画实时曲线。但这些都不是必须的。我建议第一版先用纯标准库实现核心功能，跑通了再考虑扩展。

注意：在Linux上读取CPU温度需要访问/sys/class/thermal/目录，可能需要root权限。Windows上则需要借助WMI接口，psutil的sensors_temperatures()在部分硬件上可能返回空值。这不是脚本的问题，而是操作系统和硬件驱动的限制。

3.2 核心代码逐段拆解

完整的压测脚本包含四个部分：参数解析、计算函数、进程管理、结果汇总。我一段一段来说。

参数解析部分用argparse实现，让用户能指定精度、进程数、运行时长。这里有个小技巧：默认进程数设为multiprocessing.cpu_count()，这样开箱即用。运行时长参数用--duration控制，单位是秒，默认0表示无限运行直到手动中断。

import argparse def parse_args(): parser = argparse.ArgumentParser(description='CPU压力测试 - 圆周率计算') parser.add_argument('-p', '--precision', type=int, default=10000, help='圆周率计算精度（小数位数），默认10000') parser.add_argument('-n', '--processes', type=int, default=0, help='进程数，默认等于CPU核心数') parser.add_argument('-d', '--duration', type=int, default=0, help='运行时长（秒），0表示无限运行') return parser.parse_args()

计算函数就是前面提到的chudnovsky，但要做一点改造：加入循环计算，让进程持续工作而不是算一次就退出。循环次数可以用时间来控制，比如每算完一次检查是否超时。

def stress_worker(precision, duration, result_queue): getcontext().prec = precision + 10 count = 0 start = time.time() while True: if duration > 0 and time.time() - start > duration: break pi = chudnovsky(precision) count += 1 elapsed = time.time() - start result_queue.put({ 'pid': os.getpid(), 'iterations': count, 'elapsed': elapsed, 'pi_head': str(pi)[:15] })

进程管理部分要处理一个关键问题：如何优雅地停止。如果用户按Ctrl+C，主进程会收到KeyboardInterrupt，此时需要向所有子进程发送终止信号。multiprocessing的Process对象有terminate()方法，但直接杀进程可能导致资源泄漏。更好的做法是用Event对象做信号传递，子进程在循环中检查事件状态。

def main(): args = parse_args() cpu_count = args.processes or multiprocessing.cpu_count() stop_event = multiprocessing.Event() result_queue = multiprocessing.Queue() processes = [] for _ in range(cpu_count): p = multiprocessing.Process( target=stress_worker, args=(args.precision, args.duration, result_queue) ) p.start() processes.append(p) try: for p in processes: p.join() except KeyboardInterrupt: print('\n正在停止所有进程...') for p in processes: p.terminate() for p in processes: p.join() total_iterations = 0 while not result_queue.empty(): result = result_queue.get() total_iterations += result['iterations'] print(f"进程 {result['pid']}: 完成 {result['iterations']} 次计算, " f"耗时 {result['elapsed']:.2f}秒, π前15位: {result['pi_head']}") print(f"总计算次数: {total_iterations}")

3.3 运行效果与数据记录

我在一台四核八线程的机器上跑了三次测试，每次精度10000位，进程数设为8，运行时长30秒。记录的数据如下：

从数据可以看出，多进程方案确实能把CPU吃满。温度在第三轮达到83°C，说明散热系统在持续负载下逐渐饱和。如果你发现温度上升很快然后稳定在某个值，说明散热能力就是这个水平了；如果温度持续攀升不回落，那就要检查散热器安装或硅脂状态了。

实操心得：跑测试时建议打开任务管理器或htop观察每个核心的占用情况。如果发现某些核心满载而另一些空闲，可能是进程数设置不对，或者操作系统调度策略有问题。另外，笔记本在电池模式下通常会限制CPU性能，插电测试才能得到真实数据。

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

4.1 进程启动失败或无限递归

这是Windows用户最容易踩的坑。现象是程序一运行就疯狂创建新窗口或报错RuntimeError: An attempt has been made to start a new process before the current process has finished its bootstrapping phase。原因在于Windows用spawn方式启动子进程，子进程会重新导入主模块，如果创建进程的代码不在if __name__ == '__main__':保护块内，就会无限递归。

解决方法很简单：把所有创建进程、启动进程的代码都放在if __name__ == '__main__':下面。计算函数和worker函数可以放在外面，但main()的调用必须在保护块内。

if __name__ == '__main__': main()

Linux和macOS用户通常不会遇到这个问题，因为默认用fork方式，子进程直接继承父进程内存空间。但为了代码跨平台，建议始终加上保护块。

4.2 计算速度远低于预期

有朋友反馈说他的机器跑10000位π要十几秒，而我的测试只要1秒多。排查下来发现几个常见原因。第一，Python版本太老。Python 3.11对大整数运算做了显著优化，比3.8快30%以上。第二，decimal精度设置过高。getcontext().prec设成precision + 10就够了，有人设成precision * 2，导致每次运算都在处理多余的数字。第三，在循环内重复创建Decimal对象。Chudnovsky算法中的常数（如426880、10005）应该提前转成Decimal，而不是每次迭代都转换。

还有一个隐蔽的问题：某些低功耗CPU（如Intel的Y系列或AMD的移动低压版）在检测到持续负载后会主动降频，导致计算速度越来越慢。这时候观察CPU频率变化就能确认。如果是散热问题，清理风扇或更换硅脂通常能改善。

4.3 如何验证计算结果的正确性

压力测试跑久了，你可能会怀疑：算出来的π到底对不对？验证方法很简单，拿结果的前几位和已知的π值对比。π的前20位是3.14159265358979323846。如果脚本输出的前15位是3.141592653589793，那就没问题。

但要注意，decimal模块的str()输出可能会在末尾有舍入差异。更严谨的验证方法是计算pi - Decimal('3.14159265358979323846')的绝对值，看是否小于10^(-precision+5)。如果误差在预期范围内，说明算法实现正确。

注意：不要用math.pi来验证高精度结果，因为math.pi只有双精度浮点数的精度（约15-17位有效数字），无法验证10000位的计算。

4.4 压测脚本的扩展思路

基础版本跑通之后，可以按需扩展几个实用功能。一是温度监控，用psutil每秒读取一次CPU温度并记录到CSV文件，测试结束后画温度曲线。二是频率记录，在Linux上读/proc/cpuinfo，在Windows上用psutil.cpu_freq()，观察是否降频。三是内存占用监控，高精度计算会消耗大量内存，100000位π大约需要几十MB，如果内存不足会触发交换，严重影响测试结果。

还有一个有趣的扩展是混合负载：同时跑圆周率计算和内存拷贝，模拟更真实的混合工作负载。不过这已经超出“CPU压力测试”的范畴了，属于系统级压力测试的领域。

5. 从压测脚本到性能观察工具

5.1 记录与分析CPU行为数据

单纯跑满CPU只是第一步，更有价值的是观察CPU在持续负载下的行为变化。我习惯在压测时同时记录三组数据：每秒的CPU频率、每秒的温度、以及每轮计算的耗时。把这三组数据放在同一张时间轴上，能看出很多有意思的现象。

比如在一台散热一般的轻薄本上，前30秒CPU能维持在3.5GHz，温度爬到85°C后频率降到2.8GHz，计算耗时从1.2秒增加到1.6秒。这就是典型的温度墙降频。如果换了散热更好的机器，频率可能全程稳定在3.5GHz以上，计算耗时几乎不变。这种对比能直观反映散热系统的优劣。

记录数据用Python的csv模块就够了，不需要数据库。每秒钟写一行，测试结束后用Excel或Python的matplotlib画图。我通常会把频率和温度画在双Y轴上，耗时画成散点图，一眼就能看出关联性。

5.2 不同硬件平台的实测对比

我用同样的脚本在三台机器上做了对比测试，精度统一设为10000位，进程数等于逻辑核心数，运行60秒。结果如下：

从数据能看出几个规律：桌面平台的持续性能最好，频率波动小、温度低；笔记本受散热限制明显，频率波动大；迷你主机虽然核心多，但单核性能弱，总计算次数反而不如桌面六核。这些差异在跑分软件里也能看到，但自己用圆周率脚本测出来的数据更贴近实际计算场景。

5.3 脚本的局限性与替代方案

说了这么多优点，也得客观说说局限性。Python圆周率压测的最大问题是负载类型单一。它主要压的是CPU的整数运算单元和浮点运算单元，对缓存、内存带宽、分支预测等部件的压力不够全面。如果你要测试CPU的AVX指令集性能，或者测试内存控制器的稳定性，这个脚本就不合适了。

另外，Python解释器本身会消耗一部分CPU资源，导致实际用于计算的占比不是100%。在极慢的CPU上（比如树莓派Zero），解释器开销可能占到20%以上，影响测试准确性。这种情况下，用C语言写一个等效的圆周率计算程序会更合适。

但对于大多数日常场景——快速验证散热、观察多核调度、做教学演示——Python方案已经足够好了。它的优势在于零依赖、跨平台、代码透明，这些是编译型方案比不了的。

实操心得：如果你需要更专业的压力测试，可以把这个脚本作为“预热”工具，先用它让CPU达到稳定温度，然后再跑其他测试。这样能避免冷启动对测试结果的影响。

5.4 一些让脚本更实用的小改进

最后分享几个我在实际使用中加上的小功能，每个都只增加几行代码，但实用性提升明显。

第一个是进度显示。在worker函数里每完成一次计算就向队列发送一个计数信号，主进程实时打印总进度。这样你能直观看到测试跑了多少轮，而不是干等。

第二个是自动停止条件。除了按时长停止，还可以加一个“温度超过阈值自动停止”的保护。用psutil.sensors_temperatures()读取温度，超过90°C就设置停止事件。这个功能在测试散热不好的机器时特别有用，避免过热损坏硬件。

第三个是结果保存。把每次测试的精度、进程数、总次数、平均耗时、最高温度写入一个JSON文件，方便后续对比不同机器或不同散热方案的数据。我习惯用时间戳做文件名，比如stress_20250101_143022.json，这样不会覆盖历史记录。

import json from datetime import datetime def save_result(data): filename = f"stress_{datetime.now().strftime('%Y%m%d_%H%M%S')}.json" with open(filename, 'w') as f: json.dump(data, f, indent=2) print(f"结果已保存到 {filename}")

这些改进都不复杂，但能让脚本从一个“玩具”变成一个真正可用的工具。我现在的习惯是每台新机器到手，先跑一遍标准测试（10000位、全核心、60秒），把JSON结果存档。以后换了散热器或改了电源策略，再跑一遍对比数据，效果一目了然。