subprocess.Popen() 性能随着进程数的增加而降低

Question

我有一个使用subprocess.Popen() 运行和管理许多服务的应用程序。这些服务中的每一个都会运行，直到被明确告知要关闭。我注意到从subprocess.Popen() 调用返回的时间以相当线性的速度增加，因为仲裁器产生了更多的进程。

我的基本代码如下所示：

process_list = []
for command in command_list:
  start_tm = time.time()
  process = subprocess.Popen(cmd,stdout=subprocess.PIPE,stderr=subprocess.PIPE)
  end_tm = time.time()
  print end_tm-start_tm
  process_list.append(process)

我看到end_tm-start_tm 的打印量随着我产生越来越多的进程而增加。每个command 运行的服务可以是任何顺序，我看到相同的行为。时间增加不是完全线性的，但我一直看到一个模式：第一个进程需要约 0.005 秒才能产生，第 10 个需要约 0.125 秒，第 20 个需要约 0.35 秒，依此类推。

我的仲裁进程运行超过 100 个子进程。我可以将其拆分，以便多个仲裁器分别运行较少数量的子进程，但我想首先了解问题所在。一个进程拥有许多子进程的开销是否如此之大，以至于每个额外的子进程都会增加subprocess.Popen() 的返回时间？有什么办法可以缓解这种情况吗？

编辑：我将我的单个仲裁进程一分为二。在我之前的测试中，我的仲裁器运行了 64 个进程。我为我的仲裁器创建了两个独立的配置，每个配置运行 32 个进程。我运行第一个仲裁器，让它完全启动所有 32 个进程，然后启动第二个仲裁器。

在这两种情况下，第一个进程再次启动大约需要 0.005 秒，而第 32 个也是最后一个进程大约需要大约 0.45 秒才能启动。在我之前对具有 64 个进程的单个仲裁器的测试中，第一个进程大约需要 0.005 秒才能启动，而第 64 个进程大约需要 0.85 秒。

Answer 1

不是直接回答您所注意到的“为什么”发生的问题，但我强烈建议您通过使用 ThreadPoolExecutor 管理系统资源来更改处理多处理的策略。

由于您的系统无法有效管理多于系统线程的进程，我会尝试：

>>> from concurrent.futures import ThreadPoolExecutor
>>> from multiprocessing import cpu_count
>>> with ThreadPoolExecutor(workers=cpu_count()) as pool:
    results = pool.map(lambda cmd:  subprocess.Popen(cmd,stdout=subprocess.PIPE,stderr=subprocess.PIPE), command_list)

我发现 API 很简单，资源管理也很有效，而且“陷阱”较少。

https://docs.python.org/3.6/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor.shutdown

虽然这是针对 3.6 的，但 API 在您 pip install 2.7 的 concurrent.futures 模块后基本相同。