Discovergy & Influx

[robbsen]

Hallo @paschl, vielen Dank für dein Feedback. Da du ähnlich leistungsstark unterwegs bist, gehe ich davon aus, dass der Fehler auch dieses mal bei mir liegt.

Ich nutze einen ZBOX CI327 nano und lasse ioBroker sowie influxDB in separaten LXC Containern laufen.

• ioBroker hat Zugriff auf alle 4 CPUs, 8GB RAM und eine 40 GB SSD-Disk zur Verfügung
• influxDB ebenfalls Zugriff auf alle 4 CPUs, 6GB RAM und eine 32GB SSD-Disk. Möglicherweise

habe ich einen Denkfehler?

Ich habe das Aktualisierungsintervall bei Discovergy auf 5 Sekunden eingestellt, da ich den Eigenverbrauch meiner Photovoltaikanlage OpenDTU kontinuierlich berechnen möchte.

Wenn ich das Intervall auf 60 Sekunden erhöhe, werden doch nur alle 60 Sekunden neue Werte geliefert also einmal pro Minute oder?

Hier sind meine Einstellungen bei Influx:

• Runden bei Abfrage der Zahlen auf = 4
• Schreibaktionen zusammenfassen = 0
• Schreibintervall = 600 Sekunden
• Entprellzeit = 0
• Blockzeit = 0
• trotzdem gleiche Werte aufzeichnen (Sekunden) = 0
• Minimale Differenzen zum letzten Wert = 0
• Runden bei Abfrage der Zahlen auf = 4

Verwendet wird das Ganze für meine VIS.

[crunchip]

@robbsen sagte in Discovergy & Influx:

Beides läuft auf einem Zotac mit 8 GB Ram und 4 CPU

@robbsen sagte in Discovergy & Influx:

ioBroker hat Zugriff auf alle 4 CPUs, 8GB RAM und eine 40 GB SSD-Disk zur Verfügung
influxDB ebenfalls Zugriff auf alle 4 CPUs, 6GB RAM und eine 32GB SSD-Disk. Möglicherweise

8+6=14
wie soll das gut gehen, wenn du nur 8 GB zur Verfügung hast, zumal Proxmox selbst ja auch noch einen gewissen Teil an Ram verbraucht

[robbsen]

@crunchip da hat du vermutlich Recht... ehrlicherweise habe ich das bei Container immer als Vorteil verstanden.
Bei einer VM muss ich ja Hardware fest "reservieren" sie steht also nicht mehr zu Verfügung. Container teilen sich doch die Ressourcen des Hosts. Ist natürlich klar, sie konkurrieren auch auch um diese Ressourcen. Aber ist doch immer noch sinnvoller das maximum zuzuteilen damit diese halt seltener in Engpässe geraten oder nicht?

Aber denoch stimmt es natürlich das es unsinnig ist. die kompletten 8 zuzuteilen da Proxmox hat selber auch last hat. Was fändest du für eine Aufteilung sinnvoll?

[crunchip]

@robbsen sagte in Discovergy & Influx:

Was fändest du für eine Aufteilung sinnvoll?

du siehst doch in deiner Proxmox Oberfläche, wenn du den jeweiligen LXC anklickst, was im Durchschnitt verbraucht wird, entsprechend passt du dies an und vermeidest eine Überdimensionierung.

hier als Beispiel auf eine Woche, meine Influx

@robbsen sagte in Discovergy & Influx:

Aber ist doch immer noch sinnvoller das maximum zuzuteilen damit diese halt seltener in Engpässe geraten oder nicht?

das kannst du bei der CPU so handhaben, überall 4 Kerne zuteilen ist ok, das regelt Proxmox von sich aus.

ebenfalls beim local-lvm musst du darauf achten, keine Überdimensionierung zu produzieren

ich nutze zwar noch influx in V1.x, jedoch habe ich das bei mir so

[robbsen]

@crunchip ok das hätte ich mir selber beantworten können augenroll ich brauche mehr Kaffee. Danke schon mal dafür.

Spricht aber auch dafür, dass ich wohl noch mal über ein RAM Upgrade nachdenke...

kannst du mir das mit der Überdimensionierung noch mal erläutern was du meinst? Bei dir werden zumndst die Schreibaktionen im Adapter zusammengefasst?

[crunchip]

@robbsen sagte in Discovergy & Influx:

über ein RAM Upgrade nachdenke

jep, der läuft ja auch mit 16GB

@robbsen sagte in Discovergy & Influx:

mit der Überdimensionierung noch mal erläutern was du meinst?

was genau
du musst generell darauf achten, insgesamt nicht mehr zu vergeben, als tatsächlich zu Verfügung steht, gerade beim lvm, somit bist du auf der sicheren Seite

[robbsen]

@crunchip danke dir, mache ich adjustiere grade mal nach

darf ich trotzdem noch mal zu deiner Einstellung "Schreibaktion zusammenfassen" nachfrage. da habe ich bei mir eine 0 hinterlegt.

[crunchip]

@robbsen sagte in Discovergy & Influx:

darf ich trotzdem noch mal zu deiner Einstellung "Schreibaktion zusammenfassen" nachfrage

ich hatte ebenfalls immer wieder Meldungen im Log wegen der Influx, somit habe ich herumprobiert und bin mit dieser Einstellung bis jetzt ganz gut gefahren.
https://github.com/ioBroker/ioBroker.influxdb

[robbsen]

@crunchip habs mal übernommen und bei Discovergy die speicherung wieder aktiviert... mal gucken was passiert

[Paschl]

@robbsen

Hab jetzt mal das Intervall bei Discovergy auf 30 Sekunden gesetzt und bis jetzt keine Performanceprobleme gehabt. Ich teste mich da mal an das kleinste Intervall ran

Hier mal die Statistik von der InfluxDB:

Da logge ich auch vom Bosch -SmartHome diverse Verbrauchsdaten rein. Auswertung der Solaranlage mache ich komplett in Grafana (Basis ist hier zu finden: https://github.com/c1328/ahoy-iobroker-influx-grafana) . Die Zeit noch eine VIS zu gestalten fehlt mir einfach. Das habe ich schon zig Mal angefangen und immer wieder verworfen.

Ich denke wie schon geschrieben solltest du die RAM-Zuweisung anpassen, da sonst SWAP genutzt wird und dann kann es langsamer werden. Genau aus dem Grund bin ich mit vielen Ressourcen reingestartet und hab ein Cluster aus 3 Intel NUC aufgebaut. Rein theoretisch ließe sich dann auch je nach Last der jeweilige Container auf den entsprechenden Knoten verschieben. Das brauchte ich bis jetzt aber nicht.

Mir ist gerade auch aufgefallen, dass der Discovergy-Adapter immer folgende Meldung auswirft:

State type : printedFullSerialNumber unknown, send this information to the developer ==> printedFullSerialNumber

Kommt das bei dir auch?

Die InfluxDB ist bei mir anscheinend auch nicht zu langsam, sondern die ObjectsDB vom ioBroker: slow connection to objects DB. Still waiting ... Da muss ich mich wohl erst in ein anderes Thema einlesen (Objekte: 413078, Zustände: 411457). Das ist dann wohl ein bisschen viel.

Viele Grüße

Pascal