多处理池大小- cpu_count还是cpu_count/2？

Question

我正在运行python脚本，这些脚本对相当大的aws实例(48或96 vCPU)进行批处理。multiprocessing.Pool()工作得很好:工作人员与主进程的通信很少(采用文件路径，返回True/False)。I/O和内存似乎没有受到限制。

我的性能是可变的，有时最佳速度来自池大小= vCPU数，有时来自vCPU/2，有时来自vCPU*，有些是2-4倍。它们适用于不同类型的工作，在不同的情况下，因此很难对所有这些工作进行基准测试。

对于使用什么大小的池，有经验法则吗？

P.S. multiprocessing.cpu_count()返回的数字似乎等于vCPU的数量。如果这是一致的，我想选择一些合理的倍数的cpu_count，并把它留在那里。

Answer 1

你可能会遵循很多经验法则，这取决于你已经计算出来的任务。

、

• 、物理核、

、

• 、逻辑核、

、

• 、物理核或逻辑核的数目减去1(假定为逻辑和控制保留一个核)

为了避免计算逻辑核而不是物理核，我建议使用psutil库：

import psutil
psutil.cpu_count(logical=False)

至于最终使用的是什么，对于数字密集型的应用程序，我倾向于使用物理核的数量。请记住，有些BLAS实现默认使用多线程，这可能会大大损害数据并行管道的可伸缩性。无论何时进行批处理，都要使用MKL_NUM_THREADS=1或OPENBLAS_NUM_THREADS=1 (取决于您的BLAS后端)作为环境变量，并且您应该有准线性的加速比w.r.t。物理核的数量。

Answer 2

这些数字的原因是：

1. number of vCPU:它是合理的，我们使用所有的核。vCPU/2的
2. 数:它也是合理的，因为与物理核相比，有时我们有双逻辑核。但是逻辑核实际上不会加快程序的速度，所以我们只在2-4左右使用vCPU/2.
3. vCPU*some倍数:对于一些IO密集型任务来说，这是合理的。对于这类任务，进程并不总是占据核心，因此我们可以在IO操作期间安排一些其他任务。

现在让我们分析一下情况，我想您正在运行的服务器可能是VPS。在这种情况下，逻辑核和物理核之间没有区别，因为vCPU只是一个由VPS提供程序提供的抽象计算资源。你不能真正接触到潜在的物理核心。

如果您的主进程不是计算密集型的，或者说它只是一个简单的控制器，那么您不需要为它分配一个完整的核心，这意味着您不需要减去一个。

根据您的情况，我想建议vCPU的数量。但你还是需要根据你遇到的真实情况来决定。关键的规则是：

最大限度地利用资源(尽可能多地使用核心)，尽量减少资源竞争(过多的进程将争夺资源，这将减慢整个程序)。