在scipy.optimize.differential_evolution中使用并行化时如何避免'Too many open files'错误？

Question

我正在运行一个python脚本，它使用scipy.optimize.differential_evolution为给定的数据样本找到最佳参数。我在按顺序处理我的样本。该脚本运行良好，尽管当我想利用包中实现的并行计算选项时，通过以下方式调用它:

res = scipy.optimize.differential_evolution( min_fun,
bounds   =     bnds,
updating =    'deferred',
workers  =  120
)

在计算res几次后，它抛出一个错误

File "[...]/miniconda3/envs/remote_fit_environment/lib/python3.8/multiprocessing/popen_fork.py", line 69, in _launch
child_r, parent_w = os.pipe()
OSError: [Errno 24] Too many open files

如果我分配更少的cpu，例如workers=20，它需要更长的时间，因为调用differential_evolution()的次数更多，直到错误发生。

我知道我可以提高打开文件的限制(该机器上默认为1024)，但这对我来说似乎很奇怪。由于错误起源于multiprocessing模块并可追溯到differential_evolution，我想知道scipy.optimize.differential_evolution内的并行化实现是否可能是错误的或"不干净";(虽然它是更有可能，我错过了一些东西，因为我是完全新的这整个并行/多处理的事情)?

有类似的经验或想法如何解决这个问题吗?

Answer 1

根本原因是O/S没有足够的"文件描述符";可用于如此多的进程间IPC通道(如Python的joblib.parallel()或multiprocessing模块中的IPC使用os.pipe-s来在"main" Python " interpreter"进程和(安全的)-spawn()-ed/(不安全，如其他文档所述)-fork()-ed下级进程之间进行参数通信，SciPy在调用签名workers = 120参数下重新包装和重用。

即使你"配置的O/S文件描述符数量(智能操作系统允许的)使更多的os.pipe-实例进一步工作，整个意图是不合理的，因为端到端的性能将会湮灭，因为128个工作进程将在cpu到ram的物理ram -i/O通道上存在无法解决的自我毁灭瓶颈。cpu到ram的I/o流量密度。

要求更多你很容易收到更少_{(或者根本没有)}

细节。