Kontinuierliche Schreibaktivitäten OpenHAB

[aglutz]

Hallo Zusammen

Ich betreibe OpenHAB auf einem Raspberry. Nun habe ich heute das ganze root filesystem des Raspberry auf einen NFS Server ausgelagert und musste mit schrecken feststellen, dass OpenHAB während des laufenden Betriebs mit ca. 2 MB / Sekunden auf den Server schreibt. (siehe Bild des Servers (Synology)).

Konnte bis jetzt nicht rausfinden, was die Last auf den Server verursacht (DropBox , Persistence ist nicht eingeschaltet)

Klar ist, dass es auf OpenHAB zurückzuführen ist. Solange ich OpenHAB nicht gestartet habe, habe ich keinen solchen Traffic auf dem NFS Root filesystem.

Hat da jemand eine Idee? Interessiert mich schon, denn das gleiche passiert ja auch, wenn man das root filesystem beim Raspberry auf der SD Card hat, was dann nicht wirklich gut ist.

Danke und Gruss
Adi

[Zigulle]

Hallo,

ich könnte mir vorstellen, dass es sich bei den Daten vor allem um Log-Daten handelt.
Openhab logt alle knx-Events (und ich denke mal alle anderen Events auch) sehr ausführlich mit.
Ich bin jetzt auf die schnelle überfragt, wie der log-Deamon das handelt, vor allem, weil die Log-Dateien ja von openhab selber geschrieben werden und nicht an den log-Deamon des Systems gehen.

Wenn ich auf meinem Pi (Root-system auf SD lokal) iotop laufen lasse, schreibt er nicht kontinuierlich.
Alle 2-3 Sec steigt die io-Last auf ca. 25 Kb/s an. Das liegt wesentlich unter Deinen Werten. Ich hab hier dabei so ca. 100 KNX-Items Konfiguriert, von denen vor allem die Temperatursensoren oft was auf den Bus plaudern.

Beobachte mal das logging. Imho wäre es schön, Wenn man in den Konfigurationsdateien von openhab das Log-Level einstellen könnte. Ich brauche in der Regel nicht jeden knx-Event in der Log-Datei.

Gruß
Daniel

[Jockel]

Beobachte mal das logging. Imho wäre es schön, Wenn man in den Konfigurationsdateien von openhab das Log-Level einstellen könnte. Ich brauche in der Regel nicht jeden knx-Event in der Log-Datei.

Das kannst Du in der logback.xml, z.B. mit level="WARN". Da kannst Du z.B. auch andere Logziele definieren.

[aglutz]

Hallo,

ich könnte mir vorstellen, dass es sich bei den Daten vor allem um Log-Daten handelt.
Openhab logt alle knx-Events (und ich denke mal alle anderen Events auch) sehr ausführlich mit.
Ich bin jetzt auf die schnelle überfragt, wie der log-Deamon das handelt, vor allem, weil die Log-Dateien ja von openhab selber geschrieben werden und nicht an den log-Deamon des Systems gehen.

Wenn ich auf meinem Pi (Root-system auf SD lokal) iotop laufen lasse, schreibt er nicht kontinuierlich.
Alle 2-3 Sec steigt die io-Last auf ca. 25 Kb/s an. Das liegt wesentlich unter Deinen Werten. Ich hab hier dabei so ca. 100 KNX-Items Konfiguriert, von denen vor allem die Temperatursensoren oft was auf den Bus plaudern.

Beobachte mal das logging. Imho wäre es schön, Wenn man in den Konfigurationsdateien von openhab das Log-Level einstellen könnte. Ich brauche in der Regel nicht jeden knx-Event in der Log-Datei.

Gruß
Daniel

Hi

Ich habe hier 8 KNX Punkte definiert und die Logfiles wachsen nicht entsprechend. Ist also wahrscheinlich nicht der Grund.

Habe jetzt mal in der Equinox console alle OpenHAB bundles gestoppt und die Schreiblast bleibt bestehen. Das entspricht genau dem Bild, dass die Schreiblast startet, sobald der OSGI console prompt erscheint und OpenHAB noch nicht gestartet wurde. Ich vermute jetzt mal, dass Equinox der Übeltäter ist und nicht openHAB als solches. Habe leider keine Ahnung ob das nun ein normales Verhalten von Equinox ist, wenn es über NFS mount läuft.

Gruss
Adi

[kkreuzer]

Das wunder mich schon sehr - ich vermute auch kein generelles Verhalten von Equinox in dieser Form. Normalerweise sollte sich der I/O in Grenzen halten, insbesondere, wenn man das Event-Logging (in die Datei events.log) abstellt.

Andere hier im Forum haben zur Schonung der SD-Karte auf ein tmpfs gesetzt, was wohl sehr gut funktioniert, siehe https://knx-user-forum.de/276125-post30.html und https://knx-user-forum.de/277725-post36.html.

Grüße,
Kai

[aglutz]

Das wunder mich schon sehr - ich vermute auch kein generelles Verhalten von Equinox in dieser Form. Normalerweise sollte sich der I/O in Grenzen halten, insbesondere, wenn man das Event-Logging (in die Datei events.log) abstellt.

Andere hier im Forum haben zur Schonung der SD-Karte auf ein tmpfs gesetzt, was wohl sehr gut funktioniert, siehe https://knx-user-forum.de/276125-post30.html und https://knx-user-forum.de/277725-post36.html.

Grüße,
Kai

So, das Problem ist identifiziert und gelöst. Wenn das OSGI Framework gestartet ist werden permanent die 2 unten gelisteten Files beschrieben und dies mit recht vielen Mbytes / Sekunde!:

Ich nehme jetzt mal an, dass dies der Standard ist, dass unter Linux /tmp verwendet wird .

Directory: /tmp/fileinstall--8540641384193978662 $

2743 drwxr-xr-x 2 pi pi 80 Jan 27 20:47 .
1722 drwxrwxrwt 8 root root 160 Jan 27 20:50 ..
2753 -rw-r--r-- 1 pi pi 15916487 Jan 27 20:55 addons.jar
2744 -rw-r--r-- 1 pi pi 4820753 Jan 27 20:55 removed.jar

Wer also sein /tmp Directory auf einem physischen Disk (SD Card, NFS Root) hat, der hat die von mir beschriebenen auffälligen I/O Aktivitäten.

Lösung: Auf dem Raspberry das /tmp Directory ins Memory mounten, damit die I/O Aktivität entsprechen device-schonend und schnell ausgeführt werden können. Das /tmp ins Memory umbiegen erledigt man, in dem man einfach im file /etc/defaults/tmps entsprechend die Variable RAMTMP=yes setzt und danach den Raspberry neu startet.

Hier noch ein Auflistung, wie sich die Files in ihrer Grösse verändern über einen bestimmten Zeitraum:

pi@raspberrypi /tmp/fileinstall--8540641384193978662 $ ls -ali
total 20252
2743 drwxr-xr-x 2 pi pi 80 Jan 27 20:47 .
1722 drwxrwxrwt 8 root root 160 Jan 27 20:59 ..
2753 -rw-r--r-- 1 pi pi 15916487 Jan 27 21:04 addons.jar
2744 -rw-r--r-- 1 pi pi 4820753 Jan 27 21:04 removed.jar
pi@raspberrypi /tmp/fileinstall--8540641384193978662 $ sudo iotop
pi@raspberrypi /tmp/fileinstall--8540641384193978662 $ ls -ali
total 19320
2743 drwxr-xr-x 2 pi pi 80 Jan 27 20:47 .
1722 drwxrwxrwt 8 root root 160 Jan 27 21:09 ..
2753 -rw-r--r-- 1 pi pi 14958663 Jan 27 21:10 addons.jar
2744 -rw-r--r-- 1 pi pi 4820753 Jan 27 21:10 removed.jar
pi@raspberrypi /tmp/fileinstall--8540641384193978662 $ ls -ali
total 20252
2743 drwxr-xr-x 2 pi pi 80 Jan 27 20:47 .
1722 drwxrwxrwt 8 root root 160 Jan 27 21:09 ..
2753 -rw-r--r-- 1 pi pi 15916487 Jan 27 21:10 addons.jar
2744 -rw-r--r-- 1 pi pi 4820753 Jan 27 21:10 removed.jar
pi@raspberrypi /tmp/fileinstall--8540641384193978662 $ ls -ali
total 8100
2743 drwxr-xr-x 2 pi pi 80 Jan 27 20:47 .
1722 drwxrwxrwt 8 root root 160 Jan 27 21:09 ..
2753 -rw-r--r-- 1 pi pi 3469664 Jan 27 21:11 addons.jar
2744 -rw-r--r-- 1 pi pi 4820753 Jan 27 21:11 removed.jar
pi@raspberrypi /tmp/fileinstall--8540641384193978662 $ ls -ali
total 16460
2743 drwxr-xr-x 2 pi pi 80 Jan 27 20:47 .
1722 drwxrwxrwt 8 root root 160 Jan 27 21:09 ..
2753 -rw-r--r-- 1 pi pi 12030597 Jan 27 21:11 addons.jar
2744 -rw-r--r-- 1 pi pi 4820753 Jan 27 21:11 removed.jar
pi@raspberrypi /tmp/fileinstall--8540641384193978662 $ ls -ali
total 20252
2743 drwxr-xr-x 2 pi pi 80 Jan 27 20:47 .
1722 drwxrwxrwt 8 root root 160 Jan 27 21:09 ..
2753 -rw-r--r-- 1 pi pi 15916487 Jan 27 21:11 addons.jar
2744 -rw-r--r-- 1 pi pi 4820753 Jan 27 21:11 removed.jar
pi@raspberrypi /tmp/fileinstall--8540641384193978662 $ ls -ali
total 16540
2743 drwxr-xr-x 2 pi pi 80 Jan 27 20:47 .
1722 drwxrwxrwt 8 root root 160 Jan 27 21:09 ..
2753 -rw-r--r-- 1 pi pi 15916487 Jan 27 21:11 addons.jar
2744 -rw-r--r-- 1 pi pi 1017276 Jan 27 21:11 removed.jar
pi@raspberrypi /tmp/fileinstall--8540641384193978662 $ ls -ali
total 8688
2743 drwxr-xr-x 2 pi pi 80 Jan 27 20:47 .
1722 drwxrwxrwt 8 root root 160 Jan 27 21:09 ..
2753 -rw-r--r-- 1 pi pi 4075484 Jan 27 21:11 addons.jar
2744 -rw-r--r-- 1 pi pi 4820753 Jan 27 21:11 removed.jar
pi@raspberrypi /tmp/fileinstall--8540641384193978662 $ ls -ali
total 16616
2743 drwxr-xr-x 2 pi pi 80 Jan 27 20:47 .
1722 drwxrwxrwt 8 root root 160 Jan 27 21:09 ..
2753 -rw-r--r-- 1 pi pi 12193792 Jan 27 21:11 addons.jar
2744 -rw-r--r-- 1 pi pi 4820753 Jan 27 21:11 removed.jar
pi@raspberrypi /tmp/fileinstall--8540641384193978662 $ ls -ali
total 20252
2743 drwxr-xr-x 2 pi pi 80 Jan 27 20:47 .
1722 drwxrwxrwt 8 root root 160 Jan 27 21:09 ..
2753 -rw-r--r-- 1 pi pi 15916487 Jan 27 21:11 addons.jar
2744 -rw-r--r-- 1 pi pi 4820753 Jan 27 21:11 removed.jar
pi@raspberrypi /tmp/fileinstall--8540641384193978662 $ ls -ali
total 16604
2743 drwxr-xr-x 2 pi pi 80 Jan 27 20:47 .
1722 drwxrwxrwt 8 root root 160 Jan 27 21:09 ..
2753 -rw-r--r-- 1 pi pi 15916487 Jan 27 21:11 addons.jar
2744 -rw-r--r-- 1 pi pi 1081798 Jan 27 21:11 removed.jar
pi@raspberrypi /tmp/fileinstall--8540641384193978662 $ ls -ali
total 9424
2743 drwxr-xr-x 2 pi pi 80 Jan 27 20:47 .
1722 drwxrwxrwt 8 root root 160 Jan 27 21:09 ..
2753 -rw-r--r-- 1 pi pi 4826276 Jan 27 21:11 addons.jar
2744 -rw-r--r-- 1 pi pi 4820753 Jan 27 21:11 removed.jar
pi@raspberrypi /tmp/fileinstall--8540641384193978662 $ ls -ali
total 17916
2743 drwxr-xr-x 2 pi pi 80 Jan 27 20:47 .
1722 drwxrwxrwt 8 root root 160 Jan 27 21:09 ..
2753 -rw-r--r-- 1 pi pi 13522795 Jan 27 21:11 addons.jar
2744 -rw-r--r-- 1 pi pi 4820753 Jan 27 21:11 removed.jar
pi@raspberrypi /tmp/fileinstall--8540641384193978662 $

[kkreuzer]

Hi,

super, danke für die detaillierte Auswertung!
Das ganze scheint also nur durch das Apache Fileinstall Bundle bedingt zu sein - wir benutzen das, um den "addons" Ordner zu überwachen und dort abgelegte Bundles automatisch zur OSGi-Runtime hinzuzufügen. Dazu gibt es leider im Moment auch noch keine gute Alternative.

Aber der Workaround mit tmp ins Memory klingt gut - das ist sicher auch für einige andere Programme hilfreich.

Grüße,
Kai

[Gast]

Hallo,

ich habe diesen relativ alten Beitrag gefunden und bin mir nicht ganz sicher, ob meine Frage dazu passt. Noch dazu handelt es sich im Prinzip um eine sehr Laienhafte Frage. Trotzdem kann mir vielleicht der eine oder andere hier helfen.

Es geht darum, dass ich sehr gerne analysieren würde, wo bei openHAB festgelegt wird, welche Daten über Geräte, d.h. Items geloggt werden können und wie dies ggfs. konfiguriert werden kann?

Ich habe schon relativ viel recherchiert und getestet, aber bisher konnte ich nichts herausfinden. Aus diesem Beitrag habe ich interpretiert, dass dies evtl. über das "logback"-XML Dokument im openHAB-Ordner passiert. Sehe ich das richtig? Wenn ja, für was ist dann die "logback_debug"- Datei zusätzlich gut?

Sorry, bin noch ein blutiger Anfänger. Über jede Hilfe oder jeden Tipp wäre ich sehr dankbar.

[udo1toni]

Die logback.xml konfiguriert das Logging für den normalen Start (also start.sh oder start.bat),
die logback_debug.xml wird ausgewertet, wenn im Debug-Modus gestartet wird (also start_debug.sh oder start_debug.bat)

[Gast]

Alles klar. Dann liege ich da mit meiner Annahme schon richtig, dass ich mit der logback.xml festlegen kann, welche Daten über Geräte geloggt werden können und dies eben auch in dieser Datei konfigurieren kann oder?

[udo1toni]

Genau. Aber frag mich nicht nach der genauen Formulierung, ich bin Java-Nicht-Kenner

[Gast]

Alles klar. Vielen Dank für den Hinweis. Ja, Javatechnisch geht es da glaube ich auch wirklich etwas in die tieferen Gefilde. Da wird es bei mir auch schwierig;-)

Nur um auf Nummer sicher zu gehen. In den Bindings bzw. Addons (bspw. "org.openhab.persistence.mysql-1.6.2" kann ich nicht zufällig auch/zusätzlich konfigurieren und einsehen, wie und was geloggt wird oder? Sowas geht wirklich nur mit logback und soll auch nur dort geschehen, sehe ich das richtig?

Über Antworten würde ich mich sehr freuen.

P.S.: Es geht mir wirklich nur darum, zu analysieren welche Funktionen ich für verschiedenen Items loggen kann. Also nicht um die verschiedenen Persistence Services und Rules um bspw. abhängig von Zeit, Vorgang usw. zu loggen. Nur damit kein Missverständnis entsteht.

[udo1toni]

Das Logging wird komplett über die xml-Datei gesteuert. Natürlich können nur Log-Meldungen rausfallen, die der Programmierer auch vorgesehen hat aber das kannst Du ja in den Sourcen erkennen.

[Gast]

Alles klar. Dann bleibt es bei der logback.xml-Datei für mich. Ja, da muss ich mich wohl oder übel einlesen;-) Vielen Dank. War eine große Hilfe.

[teichsta]

im Prinzip ja!

Du kannst mit der Datei im wesentlichen Filter konfigurieren. Die Log-Statements an sich müssen aber vom Entwickler des Bindings in den Code geschrieben worden sein. Du kannst Dich dann "lediglich" entscheiden ob Du sie in welcher Situation sehen willst.

Gruß,

Thomas E.-E.