ElabNET Technik Forum

Hallo zusammen,

ich weiß noch nicht, ob es ein Problem ist, daher formulier ich erst mal eine grundsätzliche Frage:

Kann ein Container (in diesem Fall OpenHAB) den Busmaster (PBM) oder vll. auch einfach nur beide USB-Schnittstellen komplett lahm legen?

Damit meine ich:

• Container "Running"
  • Busmaster Qualität geht von den sonst üblichen 100 % auf 5 % runter
  • die Auslastung steigt von sonst üblichen 8 % auf 25 %
  • einzelne Sensoren liefern gar keine Werte mehr, der Rest mal alle (der häufigere Fall gewesen), mal Totalausfall und der PBM wird als offline dargestellt
  • auch die Qualität von unbenutzten Kanälen geht von 100 % auf 5 % runter und die Auslastung von 1 % auf > 20 %
• Container "Exited"
  • Alles läuft sofort wieder normal
  • Busmaster Qualität 100 % (Anzeige wird aber erst nach Neustart aktualisiert! ), Aulastung 7 - 8 %
  • "unbenutzte" Kanäle auch wieder Qualität 100 %, Auslastung 1 %

Der Container interagiert nicht mit 1Wire, wohl aber mit allen anderen Schnittstellen (KNX, eBus, eISCP, ...) und Timeseries.
Auffällig war noch, dass der Speicher mit ca. 600 MB und ich glaub auch mal mit über 1 GB recht stark beansprucht wurde und wohl dementsprechend Warnings/Errors ausgegeben wurden.
Habe all das aber nur heute durch Zufall entdeckt (läuft schon seit 5 Tagen semistabil , 2 Sensoren liefern seit Montag keine Werte mehr, jetzt aber wieder sehr stabil).

Jetzt ist der Container seit 40 Minuten deaktiviert und alles läuft wieder stabil. So lasse ich es mal über Nacht laufen und tagsüber werde ich versuchen den Container erneut zu starten (kleine Fehler entdeckt --> KNX-GAs in der Config im Container doppelt benutzt).

Daher habe ich noch einen Tipp/Empfehlung/FR --> bei jeglichen relevanten Warnings/Errors zyklisch ein Telegramm auf ein Objekt senden.

Grüße
Adi

Hallo Adi!

Ich konnte solche Effekte nicht beobachten, hab aber bei OpenHAB auch gemischte Gefühle.
OH schrieb bei mir mehrfach den RAM voll (>2.5GB), ich konnte aber keinen negativen Effekt am TWS erkennen => Sensoren, KNX etc. weiter stabil. Nur der Logikeditor war eventuell langsamer.
Leider hilft ein Speicherlimit hier nur insofern, dass der TWS geschützt wird, der Container liefert dann aber zyklisch Fehlermeldungen ins Log, stürzt aber nicht ab, so dass der Container nicht rebootet.

Ich hab jetzt ein OH-Alpine am start, das ist etwas kleiner und macht keine PRobleme, wobei ich meine, dass das RAM Problem am Alexa Control liegt, das ich im Moment nicht installiert habe.
HINWEIS: Alexa Bindung funktioniert perfekt, nur das Control Binding, mit der man die Alexa per KNX auch steuern könnte ggf. nicht.

lg
Robert

Hallo Adalbert,

adimaster hat geschrieben: ↑Sa Aug 29, 2020 1:33 amKann ein Container (in diesem Fall OpenHAB) den Busmaster (PBM) oder vll. auch einfach nur beide USB-Schnittstellen komplett lahm legen?

Von der Theorie her nicht direkt, darum ist es ja in einem Container. Denkbar sind nur ein hoher Verbrauch von Ressourcen hinsichtlich CPU, RAM, SSD die dann in Konkurrenz zu allen anderen Diensten eines Rechners liegen. Letzteres gilt ganz allgemein für Rechner, nicht nur beim Timberwolf Server. Jedes System wird schwierig, sofern Ressourcen übernutzt werden.

Ich glaube Dir natürlich Deine Beobachtung, aber ich habe keine andere Erklärung dafür und mir ist das bisher auch nicht bekannt geworden.

adimaster hat geschrieben: ↑Sa Aug 29, 2020 1:33 amDer Container interagiert nicht mit 1Wire, wohl aber mit allen anderen Schnittstellen (KNX, eBus, eISCP, ...) und Timeseries.

Nicht mit KNX-TP direkt, sondern nur via KNXnet/IP Tunneling. Aber das sollte nichts ausmachen. Hinsichtlich TimeSeries sollte nur "lesen" zur Verfügung stehen. Allerdings könnte man mit sehr vielen Abfragen gleichzeitig schon die CPU des TWS beanspruchen, so dass für andere Prozesse nicht mehr ausreichend Ressourcen zur Verfügung stehen.

Der Timberwolf Server ist eine Maschine, welche dem Kunden einen sehr großen Freiheitsgrad bietet. Dazu gehört auch, dass der Nutzer das Recht und die Möglichkeit hat, die Ressourcen zu überlasten. Wir haben dafür - oder dagegen - keinen Schutz eingebaut, weil dies die Möglichkeiten der Nutzer limitieren würde und das Motto des Timberwolf Servers ist ja gerade "no Limit". Darum bitte ich immer auf die Ressourcennutzung zu achten.

adimaster hat geschrieben: ↑Sa Aug 29, 2020 1:33 amDaher habe ich noch einen Tipp/Empfehlung/FR --> bei jeglichen relevanten Warnings/Errors zyklisch ein Telegramm auf ein Objekt senden.

Ja. Sowohl System- als auch Errorobjekte sind geplant.

Wir führen mit der kommenden Modbus-Implementierung ein hierrachischen Errorobjektsystem ein, das dermaßen umfassend ist, dass auf ein Nutzobjekt mehrere Errorobjekte kommen können. Da sollte dann nichts mehr unüberwacht bleiben. Wenn das dann so passt für die Nutzer, dann werden wir das später schrittweise auch für andere Busse / Protokolle zur Verfügung stellen.

lg

Stefan

Hallo zusammen,

danke für die Rückmeldung.
Die gute Nachricht zuerst; in den letzten 11h verlief alles bestens :

• alle Sensoren da und haben beim Quercheck auch alle Werte geliefert
• Qualität 100%
• Auslastung 7%

Robert_Mini hat geschrieben: ↑Sa Aug 29, 2020 9:05 am Nur der Logikeditor war eventuell langsamer.

Ok, gut zu wissen. Genau das habe ich in dieser Woche auch festgestellt und mich schon gewundert, woran das liegen könnte. Und in der Tat ist der Logik Editor jetzt wieder sehr performant! Habe mir zwar den System Monitor ab und zu angesehen, konnte aber auf Anhieb nichts Gravierendes feststellen.
Alexa habe ich nicht laufen, aber einen eBus Adapter auf USB (hängt am Port neben dem PBM) --> da hatte ich gestern bemerkt, dass er viele Errors geworfen hatte. Ursache waren aber vermutlich die oben erwähnten Fehler. Nach dem Neustart des TWS lief die betroffene Logik auf dem OpenHAB auch nicht mehr.
--> Fehler korrigiert (Korrektur an Things/Items), dann lief wieder alles am OpenHAB, nicht aber am PBM.
OpenHAB Container aus --> PBM lief wieder.

StefanW hat geschrieben: ↑Sa Aug 29, 2020 10:03 am Denkbar sind nur ein hoher Verbrauch von Ressourcen hinsichtlich CPU, RAM, SSD die dann in Konkurrenz zu allen anderen Diensten eines Rechners liegen. Letzteres gilt ganz allgemein für Rechner, nicht nur beim Timberwolf Server. Jedes System wird schwierig, sofern Ressourcen übernutzt werden.

Das war auch meine einzige Vermutung, daher habe ich diesen Thread als Frage formuliert.

StefanW hat geschrieben: ↑Sa Aug 29, 2020 10:03 am Hinsichtlich TimeSeries sollte nur "lesen" zur Verfügung stehen. Allerdings könnte man mit sehr vielen Abfragen gleichzeitig schon die CPU des TWS beanspruchen, so dass für andere Prozesse nicht mehr ausreichend Ressourcen zur Verfügung stehen.

Na ja, ich schreibe schon auf die TimeSeries über KNX.
eBus --> OpenHAB --> KNX --> TimeSeries

StefanW hat geschrieben: ↑Sa Aug 29, 2020 10:03 am [...] dass der Nutzer das Recht und die Möglichkeit hat, die Ressourcen zu überlasten. Wir haben dafür - oder dagegen - keinen Schutz eingebaut, weil dies die Möglichkeiten der Nutzer limitieren würde und das Motto des Timberwolf Servers ist ja gerade "no Limit". Darum bitte ich immer auf die Ressourcennutzung zu achten.

Das finde ich auch sehr gut! Ich werde heute Nachmittag, wenn ich mehr Zeit am Stück habe, in Ruhe wieder den OpenHAB-Container starten und beobachten, was passiert und hoffen, dass es dann wieder läuft

Ich wollte überhaupt mal verstehen, ob es möglich ist, dass ein Container einen Einfluss auf die Funktion des PBMs hat und wenn ja, wie. Drum werde ich das jetzt gezielter beobachten und bei Auffälligkeiten versuchen zu reproduzieren.

StefanW hat geschrieben: ↑Sa Aug 29, 2020 10:03 am Ja. Sowohl System- als auch Errorobjekte sind geplant.

Wir führen mit der kommenden Modbus-Implementierung ein hierrachischen Errorobjektsystem ein, das dermaßen umfassend ist, dass auf ein Nutzobjekt mehrere Errorobjekte kommen können. Da sollte dann nichts mehr unüberwacht bleiben. Wenn das dann so passt für die Nutzer, dann werden wir das später schrittweise auch für andere Busse / Protokolle zur Verfügung stellen.

Das ist natürlich super, freue mich schon jetzt drauf ! Dann kann man in Ruhe Änderungen vornehmen und würde dann adhoc mitbekommen, wenn nach einiger Zeit Fehler auftreten etc.

Grüße
Adi

Hi,

nun noch kurz die Zusammenfassung:
- OpenHAB gestartet (inkl. behobener Fehler) --> alles läuft "stabil"
- Container ist dauerhaft gelb, wegen Speicher von ~ 650 MB used
- CPU ist meistens zw. 3 und 7 %
- unregelmäßig springt die CPU-Auslastung auf > 100 bis < 300 % --> Container wird dann rot (das konnte ich mir noch nicht erklären, ist wahrscheinlich aufwändiger)

Hier fände ich eine Auslastungs-History z. B. der letzten 24 h interessant. Via MouseOver Peak-/Average-Daten.

Was bedeutet eigentlich gelber/roter Status.
Also klar, wahrscheinlich Speichernutzung > 500 MB --> gelb; Prozessorauslastung > xx % rot etc.
Aber ist das dann ein "Problem"?

Grüße
Adi

Hallo Adi,

adimaster hat geschrieben: ↑So Aug 30, 2020 10:32 pm - unregelmäßig springt die CPU-Auslastung auf > 100 bis < 300 % --> Container wird dann rot (das konnte ich mir noch nicht erklären, ist wahrscheinlich aufwändiger)

Da du ein Desktop-Gerät hast, kann du versuchen die maximale CPU Nutzung des Container limitieren, wie es in der Timberwolf Oberfläche unter Container -> Information zu Docker und Portainer -> Tipps & Tricks beschrieben ist.

adimaster hat geschrieben: ↑So Aug 30, 2020 10:32 pm Was bedeutet eigentlich gelber/roter Status.
Also klar, wahrscheinlich Speichernutzung > 500 MB --> gelb; Prozessorauslastung > xx % rot etc.
Aber ist das dann ein "Problem"?

Ein Container mit 650 MB RAM alleine auf dem Desktop-Timberwolf wahrscheinlich nicht. 2-3 Container mit jeweils 650 MB sicher.

Viele Grüße,
Matthias

ms20de hat geschrieben: ↑Mo Aug 31, 2020 10:45 am Da du ein Desktop-Gerät hast, kann du versuchen die maximale CPU Nutzung des Container limitieren, wie es in der Timberwolf Oberfläche unter Container -> Information zu Docker und Portainer -> Tipps & Tricks beschrieben ist.

Guter Punkt, danke. Ist sicher nicht verkehrt.

Frage soweit für mich erst mal beantwortet.

Fazit: Ressourcen beobachten und ggf. begrenzen

Grüße
Adi