ElabNET Technik Forum

Hallo zusammen,

ich habe gerade auch das Update gemacht. Dabei ist mir aufgefallen, dass der Portainer unter Services als nicht gestartet angezeigt wird.
Ich kann mich aber ohne Probleme einloggen. Browser Cache habe ich vorher gelöscht und einmal den Browser komplett neu gestartet.

Rest sieht gut aus.

Gruß
Andreas

ms20de hat geschrieben: ↑Mo Mai 11, 2020 11:39 am

Robert_Mini hat geschrieben: ↑Sa Mai 09, 2020 1:19 pm Zurück zur IP2:
Mein TWS zeigt ein RAM-Auslastung von 98%. Auffällig ist der timeseries-DB Prozess mit 0,9GB RAM-Verbrauch.

Hallo Robert,

wir haben nichts an der TimeseriesDB geändert, woraus sich ein erhöhter RAM-Verbrauch erklären würde.

Du hast 220 Timeseries und in der Logik einige Doktor-Modi aktiv, man kann also nicht sagen die Datenbank ruhend.
Es ist nicht ausgeschlossen, dass es auch mit diesem Thema zusammen hängt, da du 1.5 GB Logik Scope Daten hast.
viewtopic.php?f=24&t=2149

Wegen der RAM Auslastung und dem roten Smiley, hast du dir schon mal deinen OpenHAB Container angesehen?
Hier werden 2,4 GB RAM benötigt, laut Portainer.

Hallo Matthias, StefanW!

Danke für die Rückmeldung und Hilfe! Sorry, ich bin jetzt auch in den "Ich hab nichts gemacht, außer das Update"-Spruch reingefallen

Die timeseries-DB ist nun wieder bei 0,5GB was für die genannte Anzahl von Timeseries vermutlich ok ist.
Vermutlich habe ich den TWS mit dem Löschen von zahlreichen Timeseries selbst beschäftigt und habe den roten Smiley damit in Verbindung gebracht.

Ich hab gerade den OpenHAB Container neu gestartet, und siehe da, der ist von den 2,5GB zurück bei 500MB, was vermutlich normal ist.
Ich beobachte das mal weiter, ich weiß ja jetzt wo ich hinsehen muss, wenn der RAM voll läuft.

Komisch ist es dennoch, denn der OH Container läuft nun seit 1 Jahr ohne Probleme und wurde nur bei Server-Reboots neu gestartet, aber nie neu deployed. Ich weiß ja nicht wie portainer seine Container neu startet, aber da sollte eigentlich nichts passieren.

Und was mir noch einfällt: neuer Router mit falscher DNS, vielleicht ist da auch bei OpenHAB was neu einzustellen???
Ich kann mich an keinen DNS beim OpenHAB Container-Erstellen erinnern - gibt es da was?

Noch was: In portainer kann man unter ressources&runtime auch Speicherlimits festlegen, hat damit jemand erfahrung? Ich denke das hätte da auch geholfen und ggf. den Container gecrashed und damit restarted, oder?

Danke und lg
Robert

Robert_Mini hat geschrieben: ↑Mo Mai 11, 2020 8:51 pm

Die timeseries-DB ist nun wieder bei 0,5GB was für die genannte Anzahl von Timeseries vermutlich ok ist.
Vermutlich habe ich den TWS mit dem Löschen von zahlreichen Timeseries selbst beschäftigt und habe den roten Smiley damit in Verbindung gebracht.

Hallo Robert, wie meinst du das mit dem "Löschen von zahlreichen Timeseries selbst beschäftigt".

Robert_Mini hat geschrieben: ↑Mo Mai 11, 2020 8:51 pm Noch was: In portainer kann man unter ressources&runtime auch Speicherlimits festlegen, hat damit jemand erfahrung? Ich denke das hätte da auch geholfen und ggf. den Container gecrashed und damit restarted, oder?

Ja da könnten die Experten mal was sagen. Ich kenne das vom normalen Rechner, wo eine VM mal außer Rand und Band geraten ist. Auf einmal war der Lahm wie ein 486 ohne Turbo Modus. Er nachdem ich es geschafft hatte die VM zu stoppen, war wieder an Arbeiten zu denken.

Sun1453 hat geschrieben: ↑Di Mai 12, 2020 7:33 am Hallo Robert, wie meinst du das mit dem "Löschen von zahlreichen Timeseries selbst beschäftigt".

Sorry, das hab ich schlecht formuliert.
Aber grundsätzlich müssen Datenbanken nach dem Löschen wieder neu „sortiert“ werden, um schnell zu bleiben => vergleichbar mit der Datenträgerdefragmentierung.

Ich vermute daher, dass der TWS eben gelegentlich so einen Vorgang anstößt und dieser eben nach dem Löschen von größeren Datenmengen auch mal länger damit „beschäftigt“ ist.

Lg
Robert

@Robert_Mini

Hattest du vorher Timeseries gelöscht, damit der TS Prozess soviel zutun hatte.

Ja, hatte ein wenig zusammengeräumt und ein paar TimeSeries gelöscht und DokModes deaktiviert.

Die 500Mb für den Timeseries-dB sind geblieben, vorher bis knapp 1Gb.

„Speicherproblem“ (der TWS lief problemlos, Anzeige war rot) war aber der OpenHAB Docker mit 2,5gb!!

Robert

Hallo,

entsprechend läuft fest konfiguriert unter 1.1.5 mein ETS Tunnel und unter 1.1.6 mein OpenHAB Container. In der ETS habe ich die PAs auch entsprechend ihrer Funktion benannt. Vielleicht könnte man ja den Namen der PAs bei der obigen Übersicht der Tunnelverbindungen unter KNX Schnittstellen noch einbringen?

Hallo Markus,

Marinux hat geschrieben: ↑Mo Mai 18, 2020 5:42 pmVielleicht könnte man ja den Namen der PAs bei der obigen Übersicht der Tunnelverbindungen unter KNX Schnittstellen noch einbringen?

Die Idee ist gut.

Allerdings denke ich, dass eine feste Zuweisung von PAs eher unüblich ist. Die ETS / VISUs / Applikationen bekommen normalerweise den nächsten freien Port zugewiesen. Ich lass mich aber gerne eines besseren belehren, hätte nur die Praxis einer festen Zuordnung nur bisher nicht wahrgenommen.

lg

Stefan

Es gibt glaube nur die Enertex oder Arcus Schnittstelle die ein festes Mapping von IP zu Tunnel erlauben, alle anderen Hersteller machen das nicht.
Unter dem Motto haben wir schon immer so gemacht und dem Angebot von einem Tunnel je Schnittstelle ist das auch kaum notwendig. In einer Multicontainer-Umgebung oder sowas wie KNX-Presso App wo jedes Handy mit der App ein eigener Client ist, ist ein definiertes Mapping aber doch deutlich im Vorteil. Reine Webbasierte Visus haben da ja auch weniger ein Problem weil viele Clients auf die eine Visu mit dem einen Tunnel am KNX agieren.
Und hier gibt es ja einige die ETS, OH, CV, NR gern parallel auf dem TWS betreiben.

OT dazu lassen sich im Portainer Reihenfolgen bei Restart definieren?

gbglace hat geschrieben: ↑Mo Mai 18, 2020 6:56 pmEs gibt glaube nur die Enertex oder Arcus Schnittstelle die ein festes Mapping von IP zu Tunnel erlauben, alle anderen Hersteller machen das nicht.

Das Thema ist nicht so einfach.

Bei den KNXnet/IP Tunnel Verbindungen wird zwischen den "Standard Tunnel Verbindungen" und den "Erweiterten Tunnel Verbindungen" unterschieden.

Nur bei den "Standard Tunnel Verbindungen" könnte man eine solche Zuordnung von "IP zu Tunnel-ID" (und damit zu der PA die dieser Tunnel-Verbindung zugeordnet wurde) zuweisen. Die seit 2019 verfügbaren "Erweiterten Tunnel Verbindungen" könnten jedoch solche hinterlegten Zuordnungen überschreiben.

Es ist also fraglich, ob es sinnvoll ist ein Leistungsmerkmal zu implementieren, das durch die Möglichkeiten der erweiterten Verbindungstypen überschrieben werden kann und den Anwender ins Chaos stürzt, weil er sich auf etwas verläßt, was dann nicht so war. Darüber müsste man dann wieder aufklären und Warnmeldungen einblenden und alles wird damit komplizierter...

lg

Stefan