一定数量的数据后 Python 子进程失败

Question

我同时使用 Python 和 Java 进行一些科学计算。 Python 将排列发送到要处理的 Java 代码。我使用带有管道数据进出的子进程对象。在大约 75k 次排列之前，该系统运行良好。那时它崩溃了。最奇怪的是它在 75k 左右排列时的一致性，无论其他变量如何变化。

Python 代码一次发送 50 个排列，但更改此数字不会影响它何时崩溃。

让 python 代码在数据的较小部分(40k，然后是 40k 等)上运行相关函数不会影响崩溃。

将同时线程的数量从 4 减少到 1 不会影响它何时崩溃。

然而，它不会在特定排列时崩溃，大约 75k(可能是 70k，可能是 81k，等等)

我完全迷惑了。这是抛出的错误:

[1:84150]  //Thread 1, permutation #84150 
Number of threads active 2
("Failure","Failure")
Traceback (most recent call last):
File "D:\TMD Projects\BE9\BE9_RestrictHB_2A_Fine\TMD_7.28.16.py", line 836, in run
returnedDataTuple = p.communicate(sentData.encode())
File "C:\Python34\lib\subprocess.py", line 959, in communicate
stdout, stderr = self._communicate(input, endtime, timeout)
File "C:\Python34\lib\subprocess.py", line 1190, in _communicate
self.stderr_thread.start()
File "C:\Python34\lib\threading.py", line 851, in start
_start_new_thread(self._bootstrap, ())
RuntimeError: can't start new thread

这是相关的代码，没有什么太复杂的:

p = subprocess.Popen(["java","-jar","WatGenDabBatchNoTP.jar","L","6","0",str(BATCH_SIZE)], stdin=subprocess.PIPE , stdout=subprocess.PIPE, stderr=subprocess.PIPE)
returnedData = "Failure"
returnedError = "Failure"
returnedTuple = ("Failure","Failure")
try:
   returnedTuple = p.communicate(sentData.encode())
   returnedData = returnedTuple[0].decode('utf-8')
   returnedError = returnedTuple[1].decode('utf-8')
except:
   PRINT("["+str(me.thread)+":"+str(number)+"]")
   PRINT("Number of threads active "+str(threading.activeCount()))
   PRINT(str(backTuple))
   PRINT(traceback.format_exc())
finally:
   #p.stdout.flush() //Flushing buffers throws an error
   #p.stdin.flush()
   #p.stderr.flush()
   p.terminate() //Terminating process doesn't help
   p.kill()

上面的代码是一个循环的一部分。它在循环的每次运行中发送 BATCH_SIZE 排列，并在达到 75-85k 时崩溃。它在 Windows 7 和 Python 3.4.2 上运行

Answer 1

一些尝试:

1. 将 BATCH_SIZE 更改为非常小的值。程序还会崩溃吗？程序是在与之前相同的循环迭代次数后崩溃，还是在处理了相同数量的记录后崩溃？

我怀疑您在每次迭代时都在泄漏一个线程。如果是这种情况，即使 BATCH_SIZE 是一个很小的数字，程序也应该在通过循环进行相同次数的迭代后用完线程。

另一方面，问题可能与循环处理的记录总数有关。改变 BATCH_SIZE 将有助于确定如果是这样的话。

1. 尝试在 finally block 中添加 p.wait()。我会先单独尝试 p.wait()(不调用 p.kill() 或 p.terminate())。

2. 与其调用您的 Java 程序，不如让它调用一个只打印一些虚拟数据的简单程序。如果问题仍然存在，它将排除 Java 程序是问题的一部分。

3. 尽可能简化程序。只使用一个处理线程。从程序的任何其他部分删除线程/子进程的使用。不是生成排列，而是预先计算每个批处理并将其保存在文件中。然后使用一个简单的 for 循环将它们提供给您的 Java 程序。这将有助于确定您调用 subprocess.Popen 的方式是否是罪魁祸首还是不是。