Ankündigung

Einklappen
Keine Ankündigung bisher.

Absturzuntersuchung

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

    #16
    Ich schau’s mir an. Am besten bis zum Fix das Plugin abschalten. Danke für den Hinweis und das unfreiwillige debuggen
    Zuletzt geändert von pfischi; 04.12.2018, 19:42.
    Sonos

    Kommentar


      #17
      Also ich habe das nochmal überprüft,

      die Anzahl der Threads ist normal. An jedem Speaker muss man sich mit mehreren Events registrieren, um alle Daten zu erhalten. Ich zähle pro Speaker 10 Threads bei mir. Ist also normal. Solange die Anzahl der Threads nicht ansteigt, ist alles ok. Ich konnte bei mir nichts festellen, habe es aber im Dauertest und ein Auge drauf.

      Gruss,

      Stefan
      Zuletzt geändert von pfischi; 04.12.2018, 22:36.
      Sonos

      Kommentar


        #18
        pfischi Kannst Du die Threads sinnvoll benennen? Dann kann man sie in der Auflistung im Backend zum Plugin zuordnen und muss nicht im Ausschlußverfahren herausfinden wo sie herkommen.
        Viele Grüße
        Martin

        Kommentar


          #19
          Zitat von Msinn Beitrag anzeigen
          pfischi Kannst Du die Threads sinnvoll benennen? Dann kann man sie in der Auflistung im Backend zum Plugin zuordnen und muss nicht im Ausschlußverfahren herausfinden wo sie herkommen.
          Ja, soweit dies unter meiner Kontrolle ist. Manches kommt direkt aus dem SoCo-Framework (Teil des Plugins). Ich mache morgen mal was fertig und stelle es zur weiteren Fehleranalyse bereit.
          Gleichzeit habe ich die letzte Stunde einen Stresstest bei mir gemacht: alle 10 Sekunden werden die Registrierungen der Speaker erneuert, was normalerweise aller 120 Sekunden passiert. Die Anzahl der Threads bleibt gleich.

          Gruss,

          Stefan
          Sonos

          Kommentar


            #20
            Im Sonos-Thread diskutieren wir auch gerade über das Sonos-Plugin. Eventuell hat sich da bei mir ein Memory-Leak eingeschlichen. Ich kann mir vorstellen, dass das hier auch ein Problem darstellt.

            Gruss,

            Stefan
            Sonos

            Kommentar


              #21
              Das Sonos-Plugin erzeugt zwar viele Threads, aber der Absturz wird bei mir durch das sml-Plugin verursacht.

              Kommentar


                #22
                Woraus schließt Du, das das SML Plugin für den Absturz verantwortlich ist?

                Kommentar


                  #23
                  Ohne sml-Plugin läuft mein System Wochen ohne Absturz, mit nur ca. zwei Tage.

                  Die Anzahl der Threads scheint vor dem Absturz auch nicht anzusteigen.

                  Der Systemload ging auf 112%.
                  Zuletzt geändert von android; 07.12.2018, 12:04.

                  Kommentar


                    #24
                    Zitat von android Beitrag anzeigen
                    Der Systemload ging auf 112%.

                    Wie misst du diesen?

                    Ich bin kein Linux-Experte, aber ps -T -p <pid> oder top -H -p <pid> soll gemäss meinen Recherchen einzelne Threads auflisten. Vielleicht siehst du so, welcher Thread schuld ist.

                    Kommentar


                      #25
                      Habe das nachträglich über das smarthomeNG Systemitem "systemload" gesehen...

                      Werde das mal probieren. Aber muss erstmal ein Testsystem zum Nachstellen aufsetzen, will nicht immer mein produktivsystem lahm legen

                      Kommentar


                        #26
                        Wenn SHNG selbst hängt, würde ich auf dessen Werte nicht mehr vertrauen, speziell nicht auf die in der Datenbank gespeicherten. Es ist ja fraglich, wann die DB zuletzt beschrieben werden konnte.

                        Wenn ich den SHNG Code sowie die Python Doku richtig verstehe, ist das auch nicht ein Prozentwert (etwa der Prozessorlast) sondern die Anzahl Prozesse in der Run Queue.

                        Kommentar


                          #27
                          Habe das mal so intepretiert. Der Wert ist ja eine Dezimalzahl die bei mir normalerweise bis zu 0.3-0.4 geht und in dem Fall 1.12 war. Der Zeitpunkt passte zumindest zu dem Zeitpunkt, wo zuletzt noch items u.Ä. aktualisiert wurden.

                          Kommentar


                            #28
                            Zitat von android Beitrag anzeigen
                            Der Zeitpunkt passte zumindest zu dem Zeitpunkt, wo zuletzt noch items u.Ä. aktualisiert wurden.
                            Genau das hatte ich befürchtet - das ist ja eigentlich zu früh. Zumal es auch noch ein Durchschnitt der vorangehenden 15 Minuten ist.
                            Interessanter wäre ja der Zustand zum Zeitpunkt des Hängens bzw. eigentlich sogar danach.

                            Wie viele Cores hat denn dein NUC? Der Wert der Run Queue ist nämlich im Verhältnis zu den Anzahl Cores zu setzen.
                            Also bei einem Core wäre 1.12 tatsächlich eine Überlastung (und damit quasi 112% Load), bei zwei Cores wären es aber nur 56%.

                            Kommentar


                              #29
                              Hab 4 cores. Hab momentan leider keine Zeit, nochmals Tests mit sml Plugin zu machen. Hoffe komme da nach Weihnachten mal zu.

                              Kommentar

                              Lädt...
                              X