Die parallele Verarbeitung der Python-Joblib funktioniert in der uWSGI-Umgebung nicht. Wie verarbeite ich parallel auf uWSGI?

Einführung

Wenn Sie maschinelles Lernen oder Deep Running mit Python durchführen, wird die Verarbeitung sehr umfangreich und es kann zu Leistungsproblemen kommen.

Vor kurzem habe ich auch eine starke Verarbeitung und habe beschlossen, eine parallele Verarbeitung hinzuzufügen, um die Leistung zu verbessern. Eine Leistungsverbesserung wurde bei Verwendung einer Bibliothek für die parallele Verarbeitung namens "joblib" lokal festgestellt.

In dem Fehler, der den gleichen Prozess in der Entwicklungsumgebung ausgeführt hat. .. .. Anscheinend funktioniert joblib in der uWSGI-Umgebung nicht. Ich habe die Maßnahmen dazu zusammengefasst.

Was ist uWSGI?

――UWSGI ist ein Anwendungsserver zum Ausführen von Webdiensten in Python.

Umweltinformationen

• python: 3.6.9
• nginx: 1.13.1
• uWSGI: 2.0.18
• joblib: 0.14.0

Joblib-Code, der unter uWSGI fehlschlägt

--Verarbeitung, die Sie parallelisieren möchten

length = 1000
def sum(i, j):
  return i + j

• Parallelisierung

from joblib import Parallel, delayed

sum_list = Parallel(n_jobs=-1)( [delayed(calc_sum)(i, j) for j in range(length) for i in range(length)])

-Jedoch, wenn ich es auf uWSGI ausführe, erhalte ich einen Fehler wie diesen

exception calling callback for <Future at 0x7fbc520c7eb8 state=finished raised TerminatedWorkerError>
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/joblib/externals/loky/_base.py", line 625, in _invoke_callbacks
    callback(self)
  File "/usr/local/lib/python3.7/site-packages/joblib/parallel.py", line 309, in __call__
    self.parallel.dispatch_next()
  File "/usr/local/lib/python3.7/site-packages/joblib/parallel.py", line 731, in dispatch_next
    if not self.dispatch_one_batch(self._original_iterator):
  File "/usr/local/lib/python3.7/site-packages/joblib/parallel.py", line 759, in dispatch_one_batch
    self._dispatch(tasks)
  File "/usr/local/lib/python3.7/site-packages/joblib/parallel.py", line 716, in _dispatch
    job = self._backend.apply_async(batch, callback=cb)
  File "/usr/local/lib/python3.7/site-packages/joblib/_parallel_backends.py", line 510, in apply_async
    future = self._workers.submit(SafeFunction(func))
  File "/usr/local/lib/python3.7/site-packages/joblib/externals/loky/reusable_executor.py", line 151, in submit
    fn, *args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/joblib/externals/loky/process_executor.py", line 1022, in submit
    raise self._flags.broken
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 {EXIT(1), EXIT(1), EXIT(1), EXIT(1)}

Problemumgehung 1: Threads funktionieren

from joblib import Parallel, delayed

sum_list = Parallel(n_jobs=-1, prefer='threads')( [delayed(calc_sum)(i, j) for j in range(length) for i in range(length)])

―― Natürlich kann es je nach Verarbeitung langsam sein, wenn Sie Threads verwenden.

Zielmethode 2: Multiprocessing

import multiprocessing
from multiprocessing import Process

with multiprocessing.Pool() as pool:
    process = [pool.apply_async(calc_sum, (i, j)) for j in range(length) for i in range(length)]
    sum_list = [f.get() for f in process]

Problemumgehung 3: Verwenden Sie Guicorn anstelle von uWSGI

Diesmal habe ich das nicht gemacht. Der Grund dafür ist, dass das Ändern des AP-Servers riskant ist, da er bereits unter uWSGI ausgeführt wurde.

Schließlich

Geschwindigkeitsvergleich

joblib ist besser lesbar und einfacher zu schreiben, aber Multiprocessing ist eine Funktion, die in Python selbst integriert ist und daher häufig eine Outperformance aufweist. Es ist auch unwahrscheinlich, dass Sie einen Fehler wie diesen machen.