InfluxDB-Adapter und Performance

[apollon77]

Hey,

ich hab jetzt auf InfluxDB umgestellt als History-Adapter 8erstmal noch parallel) und muss feststellen das der recht "Ressourcenhungrig" ist.

Wenn man genau hinschaut verwundert das nicht, weil jedes einzelne Event einzeln zur InfluxDB per HTTP geschickt wird. Die Influx kann an sich in einer JSON-Struktur auch mehrere Events auf einmal annehmen - vllt wäre das um einiges performanter?

Zusätzlich könnte man so auch noch einen "InfluxDB-Restart-Schutz" bauen weil aktuell verliert man da Daten.

Hat irgendein anderer Adapter so einen "internen Cache" von dem man ggf klauen könnte?

Ingo F

[Bluefox]

@apollon77:

Hey,

ich hab jetzt auf InfluxDB umgestellt als History-Adapter 8erstmal noch parallel) und muss feststellen das der recht "Ressourcenhungrig" ist.

Wenn man genau hinschaut verwundert das nicht, weil jedes einzelne Event einzeln zur InfluxDB per HTTP geschickt wird. Die Influx kann an sich in einer JSON-Struktur auch mehrere Events auf einmal annehmen - vllt wäre das um einiges performanter?

Zusätzlich könnte man so auch noch einen "InfluxDB-Restart-Schutz" bauen weil aktuell verliert man da Daten.

Hat irgendein anderer Adapter so einen "internen Cache" von dem man ggf klauen könnte?

Ingo F `
Wie oft werden doch die Datenpunkte geschrieben?

Bist du sicher, dass es unbedingt Adapter die CPU-Zeit nimmt?

InfluxDB selbst ist ziemlich Ressourcen-Fresser.

Was du mit "InfluxDB-Restart-Schutz" meinst ist unklar.

[apollon77]

@Bluefox:

Wie oft werden doch die Datenpunkte geschrieben? `

Gute Frage … Schaue nachher mal ob man mit ner Query "Anzahl Datenpunkte pro Zeit" kriegt Measurementübergreifend.

Am Ende sind es die States von ca. 100 HM+CUXD-Geräten, und (noch) ein bissl JavaScript-kram, WUnderground, Nut (die aber nur 5 bzw 15 minuten Intervall).

@Bluefox:

Bist du sicher, dass es unbedingt Adapter die CPU-Zeit nimmt?

InfluxDB selbst ist ziemlich Ressourcen-Fresser. `

InfluxDB läuft auf nem anderen Rechner. und ich schaue ins Top und dann ist es der iobroker-InfluxDB-Adapter-Prozess

@Bluefox:

Was du mit "InfluxDB-Restart-Schutz" meinst ist unklar. `

Wenn man aktuell die Influx (z.B. wegen Konfigänderung oder so) neu startet braucht das ein paar Sekunden … bis zu 10 manchmal.

In der Zeit ist der HTTP-Port weg und alle Requests laufen ins leere und fehlen halt. Wenn man Client-Seitig hier einen "Cache" hat der im RAM ein paar Datenpunkte hält und Sie auch zurückhält wenn es einen Schreibfehler gibt dann könnte man etwas puffern bis die DB wieder da ist und dann kommt alles nach.

Ein Flush des Caches/Buffers alle 10 oder 60 Sekunden sollte reichen (oder wenn er eine gewisse Größe erreicht hat) ...

Ich hab mal bissl Code gespickt - der History Adapter macht das so und cached damit auf DP-Ebene wann er das File schreibt.

PS: Hast auf github nen Pull-Request für Influx. Da ist ein Fehler bei getHistory und "Step"

[apollon77]

Hey Bluefox,

ich würde bei Gelegenheit (ich beobachte das mal noch ein bissl) dann mal versuchen dieses Buffering einzubauen … wenn das für Dich ok ist ...

[Bluefox]

@apollon77:

Hey Bluefox,

ich würde bei Gelegenheit (ich beobachte das mal noch ein bissl) dann mal versuchen dieses Buffering einzubauen … wenn das für Dich ok ist ... `
Natürlich ist das für mich ok. Man kann dann die Lösung auf SQL gleich portieren.

[apollon77]

Lass es mich mal für Influx probieren, dann kann man schauen … Du musst dnn Code-Reviewen ... soooo gut kenn ich mich (noch) nicht in JS aus working on it

[apollon77]

Mist. Die influxdb-Library ist an der Stelle Schrott. Die Funktion um mehrere Datenpunkte zu schreiben geht davon aus das alle Punkte zur gleichen Zeit erstellt wurden und nimmt daher immer nur das "time" vom ersten Datenpunkt und dann für alle

Die planen da nen Umbau für die 5.0.0 der Library. Ich schaue mal das es da gescheiter ist.

Ingo F

[apollon77]

Alles blödsinn und ich behaupte das Gegenteil

Die IndexDB-Library ist cool auch schon in der 4.x

Auf meinem Github-Fork hab ich mal eine erheblich erweiterte Version … läuft bei mir schon seit ein paar Tagen und habe heute Homoran gebeten auch mal zutesten

Falls noch jemand will gern mich anschreiben.

Zum neuen: siehe README.md

[apollon77]

Neue Version ist auf dem offiziellen Github … Viel Spass beim testen!

[klassisch]

Hoffe, daß meine Frage hierher passt, ansonsten mache ich ein eigenes Thema auf.

Wo kann man den Speicherort für die Influxdb festlegen? Im Adpter geht es nicht, also wohl in influxdb.

Mein System läuft auf einer eingelöteten eMMC und für die Daten habe ich eine SSD mit FAT32, damit ich die Daten im Notfall überall lesen kann.

Meine Installation scheint etwas speziell zu sein.

Das hier https://github.com/ioBroker/ioBroker.influxdb hat bei mir nicht funktioniert, ich musste auf dem Orange Pi Plus 2e mit armbian diesen Weg wählen:

https://forum.mycontroller.org/topic/24 … i-zero-opi

Es gibt aber

/etc/influxdb/influxdb.conf

Darin errate ich folgende Speicherorte:

  # Where the metadata/raft database is stored
  dir = "/var/lib/influxdb/meta"

   # The directory where the TSM storage engine stores TSM files.
  dir = "/var/lib/influxdb/data"

  # The directory where the TSM storage engine stores WAL files.
  wal-dir = "/var/lib/influxdb/wal"

Könnte ich influxdb + Adapter stoppen dieses File editieren in

  # Where the metadata/raft database is stored
  dir = "/media/SSD/influxdb/meta"

   # The directory where the TSM storage engine stores TSM files.
  dir = "/media/SSD/influxdb/data"

  # The directory where the TSM storage engine stores WAL files.
  wal-dir = "/media/SSD/influxdb/wal"

````und influx sowie den Adapter wieder starten?

Oder mache ich da etwas kaputt?

Hier [https://stackoverflow.com/questions/283 … age-folder](https://stackoverflow.com/questions/28350290/how-to-change-location-of-influxdb-storage-folder) ist es ja ähnlich beschrieben, wobei ich mit die Rechteverteilung (sudo chown influxdb:influxdb influxdb) wieder unklar ist. Ich möchte die Datenbanken ja auch regelmäßig backupen.

Reicht es, wenn ich nur data (und wal) move und meta stehen lasse wo sie sind? Das hier [https://docs.influxdata.com/influxdb/v1 ... n-overview](https://docs.influxdata.com/influxdb/v1.5/administration/config/#configuration-overview) hat für mich noch nicht die letzte Klarheit gebracht, zumal bei den wal settings auf advaced verwiesen wird.

Daten habe ich noch keine geloggt. Im alten Speicherort

/var/lib/influxdb/

gibt es in den Verzeichnissen data, meta, val jeweils eine _internal Datei. muß ich die kopieren oder wird die neu angelegt?

Oder gibt es einen influx-DB-Befehl mit dem man die Datenbanken verschieben kann? Hier [https://docs.influxdata.com/influxdb/v1 ... anagement/](https://docs.influxdata.com/influxdb/v1.5/query_language/database_management/) habe ich nichts gesehen.

Edit: Das beschriebene Vorgehen war leider nicht erfolgreich. Durch chmod 777 -R auf die einzelnen Dateien startet influx wenigstens und scheint auch die gewünschten Verzeichnisse zu nutzen. Das Syslog schreibt beim Starten:

Mar 25 10:41:19 localhost influxd[3267]: ts=2018-03-25T08:41:19.224398Z lvl=info msg="InfluxDB starting" log_id=0734xGU0000 version=1.5.0 branch=1.5 commit=6ac835404e7e64ea7299a6eebcce1ab1ef15fe3c
Mar 25 10:41:19 localhost influxd[3267]: ts=2018-03-25T08:41:19.224625Z lvl=info msg="Go runtime" log_id=0734xGU0000 version=go1.9.2 maxprocs=4
Mar 25 10:41:19 localhost influxd[3267]: ts=2018-03-25T08:41:19.328554Z lvl=info msg="Using data dir" log_id=0734xGU0000 service=store path=/media/SSD/influxdb/data
Mar 25 10:41:19 localhost influxd[3267]: ts=2018-03-25T08:41:19.328884Z lvl=info msg="Open store (start)" log_id=0734xGU0000 service=store trace_id=0734xGt0000 op_name=tsdb_open op_event=start

Aber die Datenbank läßt sich nicht verbinden:

root@orangepiplus2e:~# sudo service influxdb start
root@orangepiplus2e:~# influx
Failed to connect to http://localhost:8086: Get http://localhost:8086/ping: dial tcp [::1]:8086: getsockopt: connection refused
Please check your connection settings and ensure 'influxd' is running.
root@orangepiplus2e:~#

[apollon77]

Puuhhh … meine InfluxDB loggt mehr. Du kannst nen höheren Loglevel einschalten und ggf auch in /var/log/syslog schauen.

Die InfluxDB hat ja mit ioBroker nichts zu tun und ist eine separat installierte Software, von daher ist Support eher schwierig.

Wichtig noch: Auf 32 Bite Systemen ist bei etwas unter 2GB DB Größe (also Grösse der Daten!) Schluss.

Was hast Du für ein System?

[klassisch]

Vielen Dank für die Antwort! Dann passt das hier nicht. 2 GB habe ich in ein bis zwei Jahren voll.

Das System ist ein Orange Pi plus 2E mit einer AllWinner H3 CPU, mit Cortex A7 32bit ARM Cores.

Gesendet von meinem ZTE A2016 mit Tapatalk

[apollon77]

Die InfluxDB hat grundsätzlich noch "Data Retention" Regeln 8also wo DU Daten zusammenfassen und verdichten kannst … aber ja auch ich habe die InfluxDB inzwischen auf 64 bit laufen

[klassisch]

Habe heute nochmals versucht, eine MariaDB-Datenbank aufzusetzen, genauso erfolglos.

Hatte wie auch bei der influxDB Probleme beim Übertragen der Rechte auf die SSD.

Die wahrscheinlichste Erklärung, die ich gefunden habe: Die SSD habe ich auf FAT32 und da kann man die Rechte nicht hinübertragen.

Ich habe die Linux-Rechtebevormundung satt. Ich überlege mir, ob meine künftige ioBroker Installation unter Windows laufen kann. Vielleicht auch auf einer größeren Synology. Ich traure dem Windows Homeserver nach. Das lief super, leicht zu administrieren, keine Rechtebevormundung etc. Leider unterstützt MS das Homeserver-Paket nicht mehr, nur noch das teure Profiserver-Paket.