Hier ist die pstree -Ausgabe meiner aktuellen GridSearch, ich bin gespannt, welche Prozesse ablaufen und es gibt etwas, was ich noch nicht erklären kann.
Ich habe Sachen entfernt, die nichts miteinander zu tun haben. Curly-Klammern bedeuten Threads.
parallel -j 20 benutzt habe, um meine Python-Jobs zu starten. Wie Sie sehen können, zeigt 20* tatsächlich, dass es 20 Prozesse gibt. bash -Prozess vor jedem der Python-Prozesse ist auf die Aktivierung der virtuellen Anaconda-Umgebung mit source activate venv . 5* ). Dies liegt daran, dass ich n_jobs=5 auf GridSearchCV angegeben habe. Mein Verständnis endet hier.
Frage : Kann jemand erklären, warum es weitere 11 Python-Threads ( 11*[{python}] ) zusammen mit der Rastersuche gibt und 31 Python-Threads ( 31*[{python}] ) in jedem der fünf Rastersuchjobs erzeugt werden ?
Aktualisieren : Der Code zum Aufrufen von GridSearchCV
Update (2017-09-27) :
Ich habe einen Testcode auf gist geschrieben, damit Sie ihn bei Interesse einfach reproduzieren können.
Ich habe denselben Code auf einem Mac Pro und mehreren Linux-Rechnern getestet und das Ergebnis von @igrinis reproduziert, aber nur auf dem Mac Pro. Auf den Linux-Rechnern bekomme ich unterschiedliche Nummern als zuvor, aber konsequent. Die Anzahl der erzeugten Threads kann daher vom bestimmten Daten-Feed für GridSearchCV abhängen.
%Vor%Beachten Sie, dass der von homebrew / linuxbrew auf Mac Pro und Linux-Maschinen installierte pstree anders ist. Hier poste ich genau die Versionen, die ich benutzt habe:
Mac:
%Vor%Linux:
%Vor%Die Mac-Version scheint keine Option zum Anzeigen von Threads zu haben, was meiner Meinung nach der Grund sein könnte, warum sie nicht im Ergebnis zu sehen sind. Ich habe noch keine Möglichkeit gefunden, Threads auf dem Mac Pro zu untersuchen. Wenn Sie einen Weg kennen, kommentieren Sie bitte.
Update (2017-10-12)
In einer anderen Versuchsreihe habe ich bestätigt, dass die Einstellung der Umgebungsvariablen OMP_NUM_THREADS einen Unterschied macht.
Vor export OMP_NUM_THREADS=1 gibt es viele (63 in diesem Fall) Threads ohne unklare Verwendung wie oben beschrieben:
Keine Verwendung von Linux parallel hier. n_jobs=23 .
Nach export OMP_NUM_THREADS=1 wurden keine Threads erzeugt, aber die 3 Python-Prozesse sind immer noch da, deren Verwendung ich immer noch nicht kenne.
Ich bin anfangs auf OMP_NUM_THREADS gestoßen, weil es bei einigen meiner GridSearchCV-Jobs Fehler verursacht, Fehlermeldungen sind so etwas wie
Von sklearn.GridSearchCV doc:
n_jobs: int, Standard = 1 Anzahl der Jobs, die parallel ausgeführt werden sollen.
pre_dispatch: int oder string, optional Steuert die Anzahl der Jobs, die während der parallelen Ausführung gesendet werden. Diese Anzahl zu reduzieren, kann nützlich sein, um eine Explosion des Speicherverbrauchs zu vermeiden, wenn mehr Jobs gesendet werden, als CPUs verarbeiten können. Dieser Parameter kann sein: Keine, in diesem Fall werden alle Jobs sofort erstellt und erzeugt. Verwenden Sie diese Option für leichtgewichtige und schnell ablaufende Jobs, um Verzögerungen aufgrund von On-Demand-Spawning der Jobs zu vermeiden Ein int, der die genaue Anzahl aller erstellten Jobs angibt Ein String, der einen Ausdruck als Funktion von n_jobs gibt, wie in '2 * n_jobs'
Wenn ich die Dokumentation richtig verstehe, erzeugt die GridSearchCV eine Menge von Threads als Anzahl von Rasterpunkten und führt nur n_jobs gleichzeitig aus. Nummer 31 Ich glaube, ist eine Art Cap-Limit Ihrer 40 möglichen Werte. Versuchen Sie, mit dem Wert von pre_dispatch -Parameter zu spielen.
Weitere 11 Threads, glaube ich, haben nichts mit dem GridSearchCV selbst zu tun, da es auf der gleichen Ebene angezeigt wird. Ich denke, es sind Reste anderer Befehle.
Übrigens beobachte ich ein solches Verhalten auf Mac nicht (siehe nur 5 Prozesse, die von GridSearchCV erzeugt werden, wie man es erwarten würde), also könnte es aus inkompatiblen Bibliotheken kommen. Versuchen Sie, sklearn und numpy manuell zu aktualisieren.
Hier ist mein pstree output (Teil des Pfades gelöscht für Privatsphäre):
Beantworten Sie den zweiten Kommentar:
Das ist eigentlich dein Code. Gerade erzeugt trennbar 1d zwei Klassenproblem:
%Vor%100k Samples waren genug, um die CPU für etwa eine Minute zu belasten.
Tags und Links python multithreading scikit-learn grid-search