Wieder mal "Needing more 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]

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]

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]

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.

[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?

[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.

[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.