Wieder mal "Needing more worker threads"

[Msinn]

Morg Minütlich wegschreiben hilft nicht, da die meisten Worker Threads nur Sekunden aktiv sind. Wie bmx schreibt, kommen es meistens dazu, wenn Logiken und/oder eval Statements in großer Zahl zeitgleich laufen wollen. Das ist hier im Forum auch schon intensiv diskutiert worden.

bmx Die Angabe der benötigten Threads von Plugins hilft nicht weiter, da es nicht generell um die Anzahl Threads geht, sondern um die Anzahl Worker Thread des Schedulers.

Sisamiwe lass die von bmx vorgeschlagene Änderung lieber bleiben. Wie ich oben schon schrieb, habe ich mir dabei damals den Scheduler zerlegt und ich hatte dabei viel Zeit berbrannt. Aus der Stelle wo ein Worker Thread benötigt wird kann man im Scheduler. Icht loggen und dort wo die Warnung dann geloggt wird, ist bereits so viel Zeit vergangen, dass Die Liste der Aktiven Worker Threads zu der Zeit keinen Zusmmenhang mit der Warnung mehr hat.

[bmx]

Aus meiner Erfahrung sind das meistens parallel laufende Logiken mit annähernd gleichem Ausführungszeitpunkt die dann doch länger für eine Aufgabe benötigen als gedacht. Dann sollen neue Logiken gestartet werden aber es stehen keine Threads mehr zur Verfügung.

Wir könnten bei den Plugins einen neuen Parameter mit einpflegen der die benötigte Anzahl an Threads mit angibt. Beispielsweise ist das Telegram Plugin sehr hungrig in dieser Hinsicht (6 Threads). So könnte die Grundanzahl der Threads durch die konfigurierten Plugins bestimmt werden plus eine Anzahl von Workern.

Sisamiwe Eventuell könntest Du im Core an der Stelle wo eine Warnung von zuvielen Threads erzeugt wird gezielt eine Ausgabe aller aktuellen Threads in eine Datei machen.

[Morg]

Wenn man über ein Item auf die Threads zugreifen kann, könnte man die - zum Loggen - ggf. minütlich ausgeben oder wegschreiben? Kann man die Threadliste aus dem Admin-UI als Liste oder Dict in einem Item bekommen -> Datenbank?

Dann ließe sich zumindest beobachten, wie viele Threads aktiv sind, wie sich das entwickelt und - vor allem - wer die "überzählichen" Worker-Threads erzeugt.

Vielleicht gibts dafür ja auch eine andere, bessere Möglichkeit?

[Msinn]

Das ist nicht so einfach…

Geloggt wird nicht genau zu dem Zeitpunkt wenn der neue Worker Thread erzeugt wird (das hatte ich mal probiert einzubauen, dabei hat dann der Scheduler shng zerlegt, weil zu dem Zeitpunkt ein anderer Thread aktiv ist).

geloggt wird erst später, falls sich die Anzahl Worker Threads erhöht hat.

[Tom Bombadil]

Ok, das hatte ich so nicht verstanden (die Fehlermeldung in Kombination mit der Anzeige im shNG Admin hatte ich anders interpretiert, mein Fehler).

Könnte man denn zum Zeitpunkt des 'Overflows' vielleicht die Fehlerausschrift erweitern, damit man dem Problem auf die Spur kommt? Es wird ja schon gelogged, d.h. der Zeitpunkt ist bekannt - es sind halt nur zu wenige Infos ...

/tom

[Msinn]

Idle Threads sind nicht das Problem. Die freizugeben würde nur Rechenzeit kosten. Deswegen werden sie ja gerde als Idle gekennzeichnet und wieder reused.

Zu dem Zeitpunkt zu dem die Warnung kommt und ein neuer Worker Thread erzeugt wird, ist die Anzahl der Idle Threads 0, sie werden vorher bereits alle reused. Gezählt wird nur die Anzahl AKTIVER Worker Threads.

[Tom Bombadil]

Stellt sich denn nach diversen Log Einträgen eine stabile Anzahl Worker Threads ein?

Gestern um 19:00 ging es nach >24Std Uptime innerhalb von ca. 1.5 Stunden von 20 auf 23 hoch.
Dann Ruhe.
Heute Mittag kam dann nochmal einer dazu.
Muss ich also beobachten.

Die Frage, die sich mir logischerweise stellt - kann man denn Coreseitig nicht Threads auch irgendwann wieder freigeben? Warum muss dieser 'Ballast' für immer und ewig mitgeschleppt werden (also bis zum nächsten Neustart, der erst in Wochen sein kann)? Oder sind das doch keine 'echten' unbenutzten idles - im Sinne von 'weiss nicht, ob das noch gebraucht wird - das oxydiert da halt rum'?

/tom

[Msinn]

Stellt sich denn nach diversen Log Einträgen eine stabile Anzahl Worker Threads ein?

Falls sich keine stabile Anzahl Worker Threads einstellt, wird es DIr nicht helfen, die Anzahl Threads hochzusetzen. Du bekommst dann die Fehlermeldungen nur ein bisschen später…

Die maximale Anzahl Worker Threads stammt schon aus smarthome.py. Es ist ein Schutz, damit Python sich auf leistungsschwachen Rechnern nicht „festfräst“. Ich hatte die Grenze schon mal hoch gesetzt, in der Annahme, dass niemand mehr einen Raspberry Pi 1 einsetzt.

[Tom Bombadil]

Ich hab das kurioserweise hier neuerdings auch wieder. 'Kurioserweise' deshalb, weil die einzige Veränderung ein definitiv funktionierender und sauberer Bugfix in einem Plugin (Trovis) ist. Ein Problem gelöst, ein neues und trotzdem altbekanntes erscheint ...

Da shNG hier in einer NAS-VM mit 4 zugewiesenen Kernen und 8GB Speicher läuft: Eigentlich sollte doch in dieser Konstellation deutlich mehr drin sein. Kann man die maximale Thread-Anzahl irgendwo hochsetzen?

(jaja, ich weiss - das löst den 'root cause' nicht)

/tom

[Sisamiwe]

Sieht bei mir vergleichbar aus (insb. modules.http.* und idle), nur dass ich "nur" 17 idle habe.

Die Anzahl der "Idle" wächst aber ständig und somit startet shNG irgendwann (also bei 30 Threads) neu.

das ist aber recht aufwändig.

Gäbe es noch eine einfachere Möglichkeit?

[Morg]

Sieht bei mir vergleichbar aus (insb. modules.http.* und idle), nur dass ich "nur" 17 idle habe.

Das Problem ist immer, dass du nicht weißt, was in dem Moment passiert, wo sowas auftritt. Du könntest einen Log-Watcher aufsetzen, der beim Auftreten von zuvielen Threads (der obigen Fehlermeldung) versucht, die Daten vom Scheduler zu sichern; dazu müsste es die als Seite ohne JS geben... das ist aber recht aufwändig.

[Sisamiwe]

Wieviele Threads sind da aufgeführt?

Unbenannt.PNG

[Morg]

Hast du in der Admin-UI unter Scheduler/Threads geschaut? Wieviele Threads sind da aufgeführt?

[Sisamiwe]

Hallo,

ich hänge mich mal hier an.
Seit geraumer Zeit habe ich auch mit einer wachsenden Anzahl von Idle Threads und damit mit dem Hinweis: "Needing more worker threads than the specified maximum of 20! (23 worker threads active)" zu tun.

Ich konnte bislang nicht herausfinden, welches Plugin, Logik, Timer... das verursacht.

Wie kann ich die Quelle für diese Threads lokalisieren?
Danke Euch.

[Msinn]

Müßte dann der fehlerhafte Thread nicht unter der Plugin-ID statt unter 'idle' gelistet sein?

Nur wenn Du schaust, während die Kommunikationsstörung noch läuft. Anschließend wird in meinem Szenarion der Thread zuende bearbeitet und beendet sich dann (wird also zu einem idle Thread)