Wieder mal "Needing more worker threads"

[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

[bmx]

Was hast Du sonst noch an Plugins am Laufen?

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

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

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.

[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

[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