UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Gelöst] [1.6.0 RC4] Busmaster vs. Container - legt Container Busmaster lahm?

Grundsätzliche Diskussionen zur 1-Wire Topologie, zur Rolle der Busmaster und des Servers.
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Antworten

Ersteller
adimaster
Reactions:
Beiträge: 375
Registriert: So Apr 14, 2019 11:12 am
Hat sich bedankt: 203 Mal
Danksagung erhalten: 198 Mal

[1.6.0 RC4] Busmaster vs. Container - legt Container Busmaster lahm?

#1

Beitrag von adimaster »

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! :think: ), 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 :crying-yellow:, 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
Grüße, Adi
TWS 2600 ID: 331, VPN geschlossen, Reboot nach Rücksprache

Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#2

Beitrag von Robert_Mini »

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
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#3

Beitrag von StefanW »

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
Zuletzt geändert von StefanW am Sa Aug 29, 2020 11:49 am, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Ersteller
adimaster
Reactions:
Beiträge: 375
Registriert: So Apr 14, 2019 11:12 am
Hat sich bedankt: 203 Mal
Danksagung erhalten: 198 Mal

#4

Beitrag von adimaster »

Hallo zusammen,

danke für die Rückmeldung.
Die gute Nachricht zuerst; in den letzten 11h verlief alles bestens :dance::
  • 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! :handgestures-thumbupright: 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 :pray:

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 :handgestures-thumbsup: ! Dann kann man in Ruhe Änderungen vornehmen und würde dann adhoc mitbekommen, wenn nach einiger Zeit Fehler auftreten etc.

Grüße
Adi
Grüße, Adi
TWS 2600 ID: 331, VPN geschlossen, Reboot nach Rücksprache

Ersteller
adimaster
Reactions:
Beiträge: 375
Registriert: So Apr 14, 2019 11:12 am
Hat sich bedankt: 203 Mal
Danksagung erhalten: 198 Mal

#5

Beitrag von adimaster »

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 % :shifty: --> 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
Grüße, Adi
TWS 2600 ID: 331, VPN geschlossen, Reboot nach Rücksprache

ms20de
Elaborated Networks
Reactions:
Beiträge: 974
Registriert: Sa Aug 11, 2018 9:14 pm
Hat sich bedankt: 280 Mal
Danksagung erhalten: 498 Mal

#6

Beitrag von ms20de »

Hallo Adi,
adimaster hat geschrieben: So Aug 30, 2020 10:32 pm - unregelmäßig springt die CPU-Auslastung auf > 100 bis < 300 % :shifty: --> 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
Zuletzt geändert von ms20de am Mo Aug 31, 2020 10:45 am, insgesamt 1-mal geändert.
[ Timberwolf Entwicklung ]

TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage

Ersteller
adimaster
Reactions:
Beiträge: 375
Registriert: So Apr 14, 2019 11:12 am
Hat sich bedankt: 203 Mal
Danksagung erhalten: 198 Mal

#7

Beitrag von adimaster »

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

Grüße
Adi
Grüße, Adi
TWS 2600 ID: 331, VPN geschlossen, Reboot nach Rücksprache
Antworten

Zurück zu „1-Wire Topologie, Busmaster & Server“