staging.inyokaproject.org

Hallo,

ich habe ein Python-Programm, dass für 5 verschiedene DNS-Server configs und zone-files produziert.

Mit entsprechend vielen Einträgen benötigt das Programm zur Ausführung auf dem Test-Server-Gerät, einem Odroid c2 entsprechend lange.

Darum habe ich das Programm in 4 verschiedene Threads aufgeteilt, die die Configs gleichzeitig erzeugen.

Vorher lag die Kernauslastung beim entsprechenden Kern bei 100%, nun aber schwanken die Kerne alle zwischen 10 und 30%.

Getestet habe ich auch auf einem 4 Kern Mac, und einem 2 Kern Linux.

Benutzt habe ich dabei das Modul threading.

Übersehe ich etwas?

Danke,

Grüße,

Linzus

linzus schrieb:

Darum habe ich das Programm in 4 verschiedene Threads aufgeteilt, die die Configs gleichzeitig erzeugen.

Vorher lag die Kernauslastung beim entsprechenden Kern bei 100%, nun aber schwanken die Kerne alle zwischen 10 und 30%.

Getestet habe ich auch auf einem 4 Kern Mac, und einem 2 Kern Linux.

Übersehe ich etwas?

Das kann man wirklich nicht sagen, ohne den Code zu kennen. Es kann sein, dass Du auf gemeinsam genutzte Ressourcen zugreifst und sich die Threads deshalb gegenseitig blockieren. Es kann sein, dass Du nun mehr IO in verschiedene Dateien gleichzeitig erzeugst, was IO langsamer macht (mehr Kopfbewegungen der Festplatte(n), falls keine SSD). Da gibt es reichlich Möglichkeiten...

linzus schrieb:

Übersehe ich etwas?

CPython hat einen Global Interpreter Lock - Multithreading lohnt sich damit oft nicht, wenn das Programm CPU-Limitiert ist - vgl. z.B. auch diesen Vortrag: Understanding the Python GIL

Kennst du GIL?

https://wiki.python.org/moin/GlobalInterpreterLock

https://docs.python.org/3/c-api/init.html#thread-state-and-the-global-interpreter-lock

Ansonsten gibts auch https://docs.python.org/3/library/multiprocessing.html

Obs daran nun liegen könnte ist schwer zu sagen ohne das Programm zu kennen.

Wenn diese Sachen unabhängig voneinander sind kannst du auch einfach so mehrere Instanzen deines Programms starten und jedes mit einer Teilmenge des Problems arbeiten lassen. Dann spart man sich den Aufwand innerhalb des Programms. Je nach Situation ist das manchmal die einfachste Lösung.

Vielen Dank.

SSD ist drinnen. Der Lock ist interesssant...

frostschutz schrieb:

Kennst du GIL?

https://wiki.python.org/moin/GlobalInterpreterLock

https://docs.python.org/3/c-api/init.html#thread-state-and-the-global-interpreter-lock

Ansonsten gibts auch https://docs.python.org/3/library/multiprocessing.html

Obs daran nun liegen könnte ist schwer zu sagen ohne das Programm zu kennen.

Wenn diese Sachen unabhängig voneinander sind kannst du auch einfach so mehrere Instanzen deines Programms starten und jedes mit einer Teilmenge des Problems arbeiten lassen. Dann spart man sich den Aufwand innerhalb des Programms. Je nach Situation ist das manchmal die einfachste Lösung.

Stimmt. Ich werde mal ein Shell-Skript erstellen, und schauen ob die Performance dann besser ist...

seahawk1986 schrieb:

linzus schrieb:

Übersehe ich etwas?

CPython hat einen Global Interpreter Lock

Ach, Python hat das auch? Dann gibt es für mich ja wieder einen Grund weniger, Python statt Ruby zu nehmen.

rklm schrieb:

Ach, Python hat das auch? Dann gibt es für mich ja wieder einen Grund weniger, Python statt Ruby zu nehmen.

CPython und Pypy haben den GIL (es gibt immer wieder Bestrebungen den Loszuwerden, wie z.B. recht aktuell in Removing Python's GIL diskutiert, aber das ist halt nicht so einfach wie in Removing the GIL using Python 3 and CNC gezeigt 😉) - Jython und IronPython haben z.B. keinen GIL und bei Cython kann man ihn temporär deaktivieren.

Hallo,

@linzus: stört dich wirklich die 100% Prozessorlast oder die Laufzeit des Skripts?

Hast du das Skript testweise mal mit PyPy ausgeführt und geschaut, ob und wie viel es schneller ist?

Ansonsten wäre es gut, mal den gut zu sehen. Wie oben schon steht: Threading mach in vielen Fällen nicht so richtig Sinn.

Gruß, noisefloor

seahawk1986 schrieb:

rklm schrieb:

Ach, Python hat das auch? Dann gibt es für mich ja wieder einen Grund weniger, Python statt Ruby zu nehmen.

CPython und Pypy haben den GIL (es gibt immer wieder Bestrebungen den Loszuwerden, wie z.B. recht aktuell in Removing Python's GIL diskutiert, aber das ist halt nicht so einfach wie in Removing the GIL using Python 3 and CNC gezeigt 😉) - Jython und IronPython haben z.B. keinen GIL und bei Cython kann man ihn temporär deaktivieren.

Ja, ist genau die gleiche Situation wie bei Ruby. Möchte jetzt aber das Thema nicht weiter entführen.