Ankündigung

Einklappen

Sammelbestellung ETS5-UPGRADE gestartet...

Die Sammelbestellung für ETS5 UPGRADE ist gestartet. Infos unter: Link
Mehr anzeigen
Weniger anzeigen

Wieder mal "Needing more worker threads"

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Wieder mal "Needing more worker threads"

    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:
    Code:
    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:
    Code:
    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

    #2
    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

    Kommentar


      #3
      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.
      Viele Grüße
      Martin

      There is no cloud. It's only someone else's computer.

      Kommentar


        #4
        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

        Kommentar


          #5
          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.
          Viele Grüße
          Martin

          There is no cloud. It's only someone else's computer.

          Kommentar


            #6
            Was hast Du sonst noch an Plugins am Laufen?

            Kommentar


              #7
              Zitat von bmx Beitrag anzeigen
              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

              Zitat von Msinn Beitrag anzeigen
              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

              Kommentar


                #8
                Zitat von Tom Bombadil Beitrag anzeigen
                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)
                Viele Grüße
                Martin

                There is no cloud. It's only someone else's computer.

                Kommentar

                Lädt...
                X