NEWS
Systemlast bei Nutzung von InfluxDB
-
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.
@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 -
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?
-
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?
@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.
-
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.
-
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 -
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@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 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?@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 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...
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!!
-
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!!
@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 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?@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.
Support us
778
Online32.4k
Benutzer81.6k
Themen1.3m
Beiträge