是什么导致了我的随机：“joblib.externals.loky.process_executor.TermulatedWorkerError”错误？

Question

我正在进行基于 GIS 的数据分析，其中计算广域全国预测图（例如天气图等）。因为我的目标区域非常大（整个国家），所以我使用超级计算机（Slurm）和并行化来计算预测图。也就是说，我将预测图分成多个部分，每个部分都在自己的进程中计算（令人尴尬的并行进程），并且在每个进程中，使用多个 CPU 核心来计算该部分（地图部分进一步拆分为更小的部分）对于 CPU 核心）。

我使用 Python 的 joblib-library 来利用我可以使用的多个核心，并且大多数时候一切都运行顺利。但有时，大约有 1.5% 的概率，我会收到以下错误：

Traceback (most recent call last):
  File "main.py", line 557, in <module>
    sub_rasters = Parallel(n_jobs=-1, verbose=0, pre_dispatch='2*n_jobs')(
  File "/root_path/conda/envs/geoconda-2021/lib/python3.8/site-packages/joblib/parallel.py", line 1054, in __call__
    self.retrieve()
  File "/root_path/conda/envs/geoconda-2021/lib/python3.8/site-packages/joblib/parallel.py", line 933, in retrieve
    self._output.extend(job.get(timeout=self.timeout))
  File "/root_path/conda/envs/geoconda-2021/lib/python3.8/site-packages/joblib/_parallel_backends.py", line 542, in wrap_future_result
    return future.result(timeout=timeout)
  File "/root_path/conda/envs/geoconda-2021/lib/python3.8/concurrent/futures/_base.py", line 439, in result
    return self.__get_result()
  File "/root_path/conda/envs/geoconda-2021/lib/python3.8/concurrent/futures/_base.py", line 388, in __get_result
    raise self._exception
joblib.externals.loky.process_executor.TerminatedWorkerError: A worker process managed by the executor was unexpectedly terminated. This could be caused by a segmentation fault while calling the function or by an excessive memory usage causing the Operating System to kill the worker.

The exit codes of the workers are {SIGBUS(-7)}

是什么原因导致这个问题，有什么想法吗？以及如何确保这种情况不会发生？这很令人恼火，因为例如，如果我有 200 个地图块正在计算，其中 197 个成功，3 个出现此错误，那么我需要再次计算这 3 个地图块。

Answer 1

问：
_{“是什么原因导致这个问题，有什么想法吗？ - 我正在使用超级计算机”}

答：
a)
Python 解释器进程（即使在超级计算机上运行）位于实际的本地主机 RAM 内存中。
b)
给定 (a)，此类本地主机 CPU 核心的数量控制行为joblib.Parallel()。
c)
给定 (b) 并进行设置n_jobs = -1，并且还pre_dispatch = '2*n_jobs'使此类 Python 解释器开始请求许多loky后端特定的单独进程实例化，作为此类本地主机 CPU 核心数量的显式倍数（可以是 4、8、16、. ..、80、...8192 - 是的，取决于实际的“超级计算机”硬件/SDS 组成）
d）
给定（c），每个这样的新 Python 解释器进程（存在于 8、16、32、.. 之间的任何位置） ., 160, ... 16384 需要启动此类新的 Python 解释器进程）从本地主机 O/S 内存管理器请求新的、单独的 RAM 分配
e)
给定 (d) 此类累积的 RAM 分配（每个 Python 进程可能会要求 30 MB - 3000 MB 之间的 RAM，具体取决于实际使用的后端以及-( -launching )-Python 解释器joblib的内存（内部状态的丰富性）可能会轻松且很快地超过物理 RAM，交换开始通过在物理 RAM 和磁盘存储之间交换 RAM 内容块来模拟丢失的容量 - 与不强制进行这种交换虚拟内存容量模拟相比，其延迟会高出约 10,000 倍 - 100,000 倍缺少物理 RAM 资源f)给定 (e) “超级计算”管理通常禁止管理工具进行过度分配，并终止所有试图超额订阅 RAM 资源超出合理使用阈值或用户配置配额的进程e)给定 ( e) 并记录记录的跟踪：__main__joblib.Parallel()

...
joblib.externals.loky.process_executor.TerminatedWorkerError:
       A worker process managed by the executor
       was unexpectedly terminated. This could be caused
           by a segmentation fault while calling the function
         or
           by an excessive memory usage
       causing the Operating System to kill the worker.

上述归纳的证据链被确认为 SegFAULT（在 Python 解释器领域中不太可能）或故意 KILL，这是由于“超级计算机”违反公平使用政策，此处是由于内存使用过多。

因为SIGBUS(-7)您可能会防御性地尝试避免 Lustre 刷新并修改有关mmap-usage 的详细信息，可能会尝试阅读“ Beyond EoF ”（如果适用）：

<sub>默认情况下，Slurm 在完成每个作业步骤后刷新 Lustre 文件系统和内核缓存。如果多个应用程序在计算节点上同时运行（来自单个 Slurm 作业的多个应用程序或多个作业），结果可能会导致性能显着下降，甚至出现总线错误。当单个计算节点上同时执行更多应用程序时，故障会更频繁地发生。使用 Lustre 文件系统时，故障也更常见。

有两种方法可以解决这个问题。一种是禁用缓存刷新，这可以通过LaunchParameters=lustre_no_flush在 Slurm 配置文件“ slurm.conf”中添加“”来完成。</sub>

请咨询您的“超级计算机”技术支持部门适用的公平使用政策，以获得有效的上限详细信息。

接下来，pre_dispatch如果仍然想使用单节点进程复制策略，而不是其他 RAM 阻塞更少、更高效的 HPC 计算策略，则不要将代码重构为那么多进程。