Gevent monkeypatching brechen multiprocessing

Ich versuche, Multiprocessing-Pool zu verwenden, um eine Gruppe von Prozessen auszuführen, von denen jeder einen gevent-Pool von Greenlets betreibt. Der Grund dafür ist, dass es eine Menge Netzwerk-Aktivität gibt, aber auch eine Menge CPU-Aktivität, um meine Bandbreite und alle meine CPU-Kerne zu maximieren, brauche ich mehrere Prozesse und gevent's async monkey patching. Ich verwende den Multiprocessing-Manager, um eine Warteschlange zu erstellen, auf die die Prozesse zugreifen, um Daten zu verarbeiten.

Hier ist ein vereinfachtes Fragment des Codes:

  • Flaschen-Blaupausen mit gevent arbeiten außerhalb des Anwendungskontextes
  • Was ist der sauberste Weg, um einen Python-Multiprocessing-Arbeiter zu stoppen, der an einer Schlange in einer Endlosschleife angeschlossen ist?
  • Kann man einen kleinen Teil einer App gevent verwenden oder muss die ganze App umschalten?
  • Überprüfe eine Liste ständig und tue etwas, wenn die Liste Elemente hat
  • Python, gevent, urllib2.urlopen.read (), Download Beschleuniger
  • Multiprocessing vs gevent
  • import multiprocessing from gevent import monkey monkey.patch_all(thread=False) manager = multiprocessing.Manager() q = manager.Queue() 

    Hier ist die Ausnahme, die es produziert:

     Traceback (most recent call last): File "multimonkeytest.py", line 7, in <module> q = manager.Queue() File "/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/managers.py", line 667, in temp token, exp = self._create(typeid, *args, **kwds) File "/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/managers.py", line 565, in _create conn = self._Client(self._address, authkey=self._authkey) File "/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/connection.py", line 175, in Client answer_challenge(c, authkey) File "/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/connection.py", line 409, in answer_challenge message = connection.recv_bytes(256) # reject large message IOError: [Errno 35] Resource temporarily unavailable 

    Ich glaube, das muss auf einen gewissen Unterschied zwischen dem Verhalten des normalen Sockelmoduls und dem Gevent-Sockelmodul zurückzuführen sein.

    Wenn ich innerhalb des Unterprozesses monkeypatch bin, wird die Warteschlange erfolgreich erstellt, aber wenn der Teilprozeß versucht, () aus der Warteschlange zu erhalten, tritt eine sehr ähnliche Ausnahme auf. Die Steckdose muss aufgrund der großen Anzahl von Netzanforderungen in den Teilprozessen monkeypatched sein.

    Meine Version von gevent, die ich glaube, ist die neueste:

     >>> gevent.version_info (1, 0, 0, 'alpha', 3) 

    Irgendwelche Ideen?

  • Ordentlich passieren Sie Positionsargumente als Args und optionale Argumente als kwargs von argpase zu einer Funktion
  • Generiere eine Liste von Argumenten in ordnungsgemäßer Reihenfolge von args und kwargs?
  • Syntaxfehler beim Versuch, Argumente zu parsen Python-Shell
  • Verwirrung beim Verständnis von Tupel und * Args in Python
  • Wie benutzt man * args in einer Funktion?
  • Python-Konvertierung * Args zur Liste
  • 5 Solutions collect form web for “Gevent monkeypatching brechen multiprocessing”

    monkey.patch_all(thread=False, socket=False)

    Ich bin in einer ähnlichen Situation in die gleiche Frage gevent/monkey.py und habe diese in Zeile 115 in gevent/monkey.py unter der Funktion patch_socket() _socket.socket = socket.socket : _socket.socket = socket.socket . Das kommentieren diese Linie aus verhindert den Bruch.

    Dies ist, wo gevent ersetzt die stdlib socket Bibliothek mit eigenen. multiprocessing.connection nutzt die socket Bibliothek ganz aus und ist anscheinend nicht tolerant gegenüber dieser Änderung.

    Im Einzelnen sehen Sie dies in jedem Szenario, in dem ein Modul, das Sie importieren, einen gevent.monkey.patch_all() Aufruf ohne Einstellung socket=False ausführt. In meinem Fall war es grequests , die das taten, und ich musste das Patching des Socket-Moduls überschreiben, um diesen Fehler zu beheben.

    Die Anwendung von Multiprocessing im Rahmen von gevent ist leider bekannt, dass es Probleme gibt. Ihre Begründung ist jedoch vernünftig ("eine Menge Netzwerkaktivität, aber auch eine Menge CPU-Aktivität"). Wenn Sie möchten, schauen Sie auf http://gehrcke.de/gipc . Dies ist in erster Linie für Ihren Anwendungsfall konzipiert. Mit gipc, können Sie leicht ein paar voll gevent-bewusst Kind Prozesse und lassen Sie sie kooperativ miteinander und / oder mit dem Elternteil durch Pipes sprechen.

    Wenn Sie spezielle Fragen haben, sind Sie herzlich willkommen, um zu mir zurückzukehren.

    Wenn du die ursprüngliche Warteschlange benutzt hast, dann kodierst du normalerweise mit monkey gepatchter Sockel.

     import multiprocessing from gevent import monkey monkey.patch_all(thread=False) q= multiprocessing.Queue() 

    Ihr bereitgestellter Code funktioniert für mich unter Windows 7.

    BEARBEITEN:

    Entferne vorherige Antwort, weil ich deinen Code auf Ubuntu 11.10 VPS ausprobiert habe und ich bekomme den gleichen Fehler.

    Schau ist wie Eventlet auch dieses Problem

    Schrieb einen Ersatz Nose Multiprocess Plugin – das sollte man gut mit allen Arten von verrückten Gevent-basierte Patching spielen.

    https://pypi.python.org/pypi/nose-gevented-multiprocess/

    https://github.com/dvdotsenko/nose_gevent_multiprocess

    • Wechselt von multiprocess.fork zu plain subprocess.popen für Worker-Prozesse (behebt Modul-Ebene fehlerhaft geteilte Objekte Probleme für mich)
    • Umschalten von multiprocess.Queue zu JSON-RPC über HTTP für Master-to-Clients RPC
    • Dies kann nun theoretisch erlauben, dass Tests auf mehrere Maschinen verteilt werden
    Python ist die beste Programmiersprache der Welt.