Wieder mal "Needing more worker threads"

[Tom Bombadil]

Hallo,

das Thema scheint schon hier und hier behandelt worden zu sein, ich weiß aber nicht so recht, wie ein guter Lösungsansatz aussehen würde.

Betroffen ist das Trovis-Plugin. Alle paar Tage (sehr unregelmäßig) kommt es offensichtlich zu vereinzelten Lesefehlern aus der Schnittstelle /dev/trovis. Diese ist per Service (socat) auf IP+Port eines RS232-LAN-Adapters im Netzwerk gemapped. Die Device wird im Minutentakt wie eine serielle Schnittstelle per pymodbus ausgelesen, dann kommt irgendwann Tage später:

2019-12-30  01:16:28 ERROR    plugins.trovis557x.poll_device Method plugins.trovis557x.poll_device exception: 'AttributeError' object is not iterable
Traceback (most recent call last):
  File "/usr/local/smarthome/lib/scheduler.py", line 522, in _task
    obj()
  File "/usr/local/smarthome/plugins/trovis557x/__init__.py", line 84, in poll_device
    self.verarbeiteWerte(ids_mit_werten, 'register')
  File "/usr/local/smarthome/plugins/trovis557x/__init__.py", line 238, in verarbeiteWerte
    for id, buswert in _ids_mit_werten:
TypeError: 'AttributeError' object is not iterable

Das geht dann für 2-3 Tage sporadisch so weiter (stunden-/tagelang ist alles ok, dann wieder mal ein oder einige wenige Lesefehler, dann wieder alles ok). Irgendwann kommt dann:

2019-12-30  10:42:58 ERROR    lib.scheduler     Needing more worker threads than the specified maximum of 20!

Danach ist dann wieder für 10/12/14 Tage Ruhe, selbst wenn kein Neustart durchgeführt wird.

Als Lösung könnte man natürlich das Plugin so umschreiben, dass die Verbindung zur Schnittstelle jedesmal neu aufgebaut wird, oder über try/except ausgelesen wird. Ich bin mir aber nichtmal sicher, ob dort tatsächlich das Problem liegt, denn im Grunde müsste man die gesamte Strecke shNG --> Plugin mit Abfrage-Routinen ---> /dev/trovis-Dienst --> Adapter jedesmal neu aufbauen (samt Service-Neustart). Schließlich hat ja auch der Adapter einen seriellen Buffer, der vielleicht nur nicht schnell genug antwortet.

Hat jemand einen Tip, wie man hier sinnvoll an eine Fehlerbehebung herangehen könnte?

/tom

[Onkelandy]

Hab das Problem auch immer wieder. Teils über 20 Idle Threads. Würde mich interessieren ob und wie man raus finden kann woher die kommen

[Msinn]

Dazu muss man im Admin Interface auf die Threads Seigte gehen und schauen von welchem Plugin es viele Threads gibt.

Das funktioniert natürlich nur, wenn der Autor des entsprechenden Plugins die Threads auch benannt hat. Sonst steht da nur eine Reihe von Thread-nn Einträgen. In diesem Fall hilft nur die Plugins, die man im Verdacht hat zu disablen und zu schauen ob das Thread Wachstum nicht mehr auftritt.

Ich hatte es letztens wieder beim HUE Plugin. Ich hatte in dem Plugin schon mal eine Konstellation beseitigt, die zum Thread Wachstum führte, es gibt aber scheinbar immer noch eine...

Das beseitigte Problem war, dass bei den Abbruch einer Verbindung schlicht übersehen wurde den Thread zu beenden.

[Tom Bombadil]

Bringt hier leider nicht viel, da man von dort aus nicht weiter 'reinleuchten' kann, wo die 'idle' threads denn herkommen. Auffällig ist, dass auch in den beiden von mir oben verlinkten Fällen Kommunikationsfehler die Ursache zu sein scheinen. Das Trovis-Plugin selbst scheint sich ordnungsgemäß zu verhalten (plugins.trovis557x.poll_device):

CP Server	(14 threads)	Ja
HTTPServer	(2 threads)	Ja
idle	(21 threads)	Ja
Main	140277704193792	Ja
plugins.trovis557x.poll_device	140275457537792	Ja
Scheduler	140277625165568	Ja

/tom

[Msinn]

Ok, ich habe bisher nie ein Problem gehabt, wenn die nur Anzahl der Idle Threads hoch war. Das bedeutet aber, dass es einen Zeitpunkt gab, zu dem die Anzahl der genutzten Threads hoch war, diese Threads inzwischen aber wieder abgebaut wurden (jetzt also idlen).

Die Angaben von Dir bedeuten übrigens nicht unbedingt, dass sich das trovis557x Plugin ordnungsgemäß verhält. Denkbar wäre ein Szenario, wo bei Störung der Kommunikation der jeweilige Thread hängt. Es wird jedoch per Scheduler periodisch ein neuer Thread gestartet. Wenn die Kommunikation wieder funktioniert, werden alle Threads nacheinander abgearbeitet und beendet.

[bmx]

Was hast Du sonst noch an Plugins am Laufen?

[Tom Bombadil]

Was hast Du sonst noch an Plugins am Laufen?

Das Produktivsystem ist recht übersichtlich:

Typ	Konfig Name	Plugin	Version	Multi-Instance
SmartPlugin	BackendServer	backend	1.5.15	Nein
SmartPlugin	cli	cli	1.4.2	Nein
SmartPlugin	weather_darksky	darksky	1.5.0.2	Ja
SmartPlugin	database	database	1.5.7	Ja
SmartPlugin	helios	helios	1.4.2	Nein
SmartPlugin	nw	network	1.3.1	Nein
SmartPlugin	trovis557x	trovis557x	0.1.a	Nein
SmartPlugin	uzsu	uzsu	1.5.3	Nein
SmartPlugin	WebSocket	visu_websocket	1.5.0	Nein
SmartPlugin	Webservices	webservices	1.5.0.5	Nein

Es wird jedoch per Scheduler periodisch ein neuer Thread gestartet. Wenn die Kommunikation wieder funktioniert, werden alle Threads nacheinander abgearbeitet und beendet.

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

/tom

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

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

[Morg]

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

[Sisamiwe]

Wieviele Threads sind da aufgeführt?

Unbenannt.PNG

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

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?

[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

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