Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[darkbrain85]

Ne, es ist vielleicht noch nicht richtig verstanden worden:

Ich habe kein Problem in dem Sinne das was nicht oder schlecht funktioniert.
Ich hätte es einfach gerne noch etwas performanter.

Ich schrieb das komplexe Diagramme ein paar Sekunden brauchen. Mit ein "paar" meine ich auch ein paar... 2-3 wenn es schlecht läuft. Also kein wirkliches "Problem"... ich will es nur noch performanter haben.

Kein Grund ein Problem zu suchen wo keines ist...

Aber ist dann an dieser Stelle auch erledigt. :+1:

[A Former User]

@darkbrain85 Wie sieht denn ein "komplexes Diagramm" aus? Welchen Zeitraum zeigst du an? Wieviele Messpunkte müssen dafür ausgewertet werden?

Bitte poste mal Screenshots oder ein paar Statistiken zu deiner Datenbank.

Ich denke es macht mehr Sinn in die Anzahl an zu verarbeitenden Daten zu investieren.
Problemlösung durch bessere Hardware ist nur sinnvoll wenn es gar nicht anders geht.

[Homoran]

@darkbrain85
Dann sollen wir mal suchen wo denn das Problemchen wirklich sitzt.

Oben schreibst du dass deine Konfig "gerade so" zurechtkommt.
Jetzt spezifizierst du das, dass er Aufbau eines Charts in der vis das Nadelöhr sei.

Jetzt ist natürlich die Frage - was diesen Chartaufbau in der vis "behindert".

• Das Auslesen der Rohdaten aus Influx?
  • Die Plattengeschwindigkeit
  • Die Busgeschwindigkeit
  • Die Berechnung der benötigten und aus der Datenbank zu extrahierenden Datenpunkte
  • Die Geschwindigkeit der Datenbank
• Das Berechnen der Mittel ( resp. Min/Max oder sonstiger Agreggationen)
• Das Rendern der Grafik auf dem Bildschirm (welche Hardware ist dies?)
• Der Transport der Daten zu dem Frontend (LAN [GBit?] oder WLAN)

Mag sein, dass ich da noch etwas vergessen habe, aber an dem Prozess bis zur Darstellung auf dem Frontend sind viele Faktoren beteiligt

[darkbrain85]

Hi!

tatsächlich stimmte etwas nicht. Ich dachte tatsächlich das die etwas langsamere Ausführung an der Datenmenge liegt.
Der Datastore auf dem ESXi hatte schlicht nicht genug freien Speicher. Ich hatte vor einigen Tagen die Virtuelle Festplatte des Debian Servers vergrößert, aber offensichtlich nicht darauf geachtet ob noch genug Luft auf der SSD ist.

Das sorgte offensichtlich für Schwierigkeiten beim Influx. Interessant ist, dass die Last zwar höher war, aber keinerlei Daten verloren sind (jedenfalls sieht es nicht so aus). Leider hat auch die Web Konsole des ESXi keinerlei Warnung erzeugt. Ich habe es nur in den Logs finden können.

Jetzt laufen die Abfragen tatsächlich ganz entspannt bei halber CPU Last.

Schon spannend... Alles funktioniert wie immer. Nur minimal langsamer mit CPU Lastpeaks. Dabei auf nicht verfügbaren Speicherplatz zu schließen, war nicht so einfach...

Der neue Server kommt trotzdem die Tage hier an. Das RAM Problem besteht ja immer noch. Da brauche ich einfach etwas mehr Luft nach oben für die VM's.

[Homoran]

@darkbrain85 sagte in Systemlast bei Nutzung von InfluxDB:

Das RAM Problem besteht ja immer noch.

Und da bist du sicher dass das existiert?
http://www.linuxatemyram.com

[darkbrain85]

Ja, ganz sicher... ;-) Die Speicherverwaltung von Linux ist mir durchaus geläufig.

Da geht es auch weniger um den RAM in der iobroker VM, sondern um den Gesamtspeicher den ich im ESXi an VM's Verteilen kann. Unter anderem soll Influx von iobroker getrennt werden, damit ein eventuelles recovery von iobroker nicht die Datenbank beeinflusst. Nur sind mehr VM's aktuell wegen "nur" 16GB RAM schwierig...

Weiß jemand was genau InfluxDB da bei nicht verfügbarem HDD Platz macht? Irgendwie scheint Datenverlust ja aktiv verhindert zu werden. Wird da automatisch komprimiert oder so?

[A Former User]

@darkbrain85 16GB Ram ist wirklich nicht wenig, was läuft denn bei dir an Kleinkram?!? Ich habe mit 16GB bei mir noch "unendlich" Platz und bei mir läuft influxdb, pihole, iobroker, openvpn, motioneye, grafana, chronograf, collectd, telegraf, fhem, ...

Da bei influxdb sicher einiges im RAM läuft, kann ein HDD disk full Problem vielleicht unbemerkt bleiben. Aber das ist jetzt nur geraten.

[darkbrain85]

Du vergisst die beiden Windows VM's bei mir. Die eine hat nur 3 GB für PRTG, aber die andere ist ein Remote Desktop mit Windows 10. Da wären 8 statt jetzt 4 GB RAM ein Traum...

Generell kann man nie genug RAM haben wenn man virtualisiert. Vor allem dann nicht, wenn man auch mal die ein oder andere VM zum testen benötigt.

[Strobi]

Hallo zusammen,
auf meinem RPI4 mit 4GB Speicher habe ich ioBroker mit einigen Skripten laufen und logge 123 Datenpunkte mit - teilweise im Sekunden-Takt.

Ist es normal, dass die CPU-Last dann so hoch ist?
Kann ich an der InfluxDB etwas optimieren, um die CPU Last zu verringern, ohne dabei Datenverlust zu erleiden?
Dargestellt werden die Daten-Punkte mit Grafana.

Über Eure Rückmeldung würde ich mich sehr freuen.
Strobi

[Thomas Braun]

@strobi sagte in Systemlast bei Nutzung von InfluxDB:

teilweise im Sekunden-Takt.
Ist es normal, dass die CPU-Last dann so hoch ist?

Ja.
Und was tut der teamviewerd und beam.smp da auf der Kiste?

[Strobi]

@thomas-braun sagte in Systemlast bei Nutzung von InfluxDB:

Und was tut der teamviewerd und beam.smp da auf der Kiste?

Was ist denn beam.smp - das habe ich nicht bewusst installiert...

[Thomas Braun]

@strobi

Das kommt eigentlich nur mit einem Desktop Environment zusammen auf die Kiste. Aber kann ja nicht sein, Server laufen ja ohne Desktop.
Oh. TeamViewer? Schaust du damit etwa ein Terminal an?

Im Ernst: Schalt den Desktop an der Kiste aus!!

[Strobi]

@thomas-braun sagte in Systemlast bei Nutzung von InfluxDB:

Im Ernst: Schalt den Desktop an der Kiste aus!!

Danke für Deine schnelle Rückmeldung.
Das hilft mir aber beim Thema InfluxDB & Ressource nicht wirklich etwas, oder?

[Thomas Braun]

@strobi sagte in Systemlast bei Nutzung von InfluxDB:

Das hilft mir aber beim Thema InfluxDB & Ressource nicht wirklich etwas, oder?

Dann wäre der Krempel aber schon mal aus dem Weg.
Und wie gesagt: Server = Headless
Wegen Performance, Sicherheit, Bequemlichkeit usw.