UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[A Former User]

@darkbrain85 Hi, ich würde dir zu einem hp proliant Gen 8 raten, gibt's gebraucht in der Bucht für um die 300... Aber die sind ewig tief..

Ansonsten halt Mal ne andere CPU testen...

[darkbrain85]

@ilovegym
Die sind leider raus. Die Tiefe passt nicht.
Außerdem habe ich mit den großen Kisten keine guten Erfahrungen was den Stromverbrauch betrifft.

Ich habe mir gerade einen Fujitsu T120 S3p mit Xeon E3 1265Lv2 geordert. Gab es für relativ kleines Geld... Im schlimmsten Fall kann ich die CPU daraus in meinen Microserver stecken.

Sollte das ganze Gerät allerdings akzeptabel sein, werde ich vermutlich doch ohne 19" Ghäuse leben müssen. Immerhin kann der auch 32GB RAM. Mit 24 GB wird er geliefert. Die CPU sollte knapp doppelt so schnell sein wie der bisherige i3.

Verrückt welche Rechenleistung man benötigt wenn man iobroker ernsthaft betreibt... ;-)

[Homoran]

@darkbrain85 sagte in Systemlast bei Nutzung von InfluxDB:

Verrückt welche Rechenleistung man benötigt wenn man iobroker ernsthaft betreibt...

Das kann ich nicht bestätigen.
Ich habe meine komplette ioBroker Installation über Jahre (ohne Unterbrechung) auf einem Tinkerboard laufen gehabt.
Bin jetzt nur wegen der Möglichkeit von Snapshots auf eine Proxmox VM auf NUC umgestiegen

[darkbrain85]

@Homoran
Das hängt halt stark davon ab was man damit macht.

Bei mir ist halt VIS mit Flot und InfluxDB der Ressourcenfresser.
Und selbst da kommt es noch darauf an wie es konfiguriert ist und welche Datenmengen man damit verarbeitet.

Klar geht das auch alles etwas schonender, aber ich bin halt ein Datenmessie...

[Homoran]

@darkbrain85 sagte in Systemlast bei Nutzung von InfluxDB:

Bei mir ist halt VIS mit Flot und InfluxDB der Ressourcenfresser.

Hab ich auch gehabt :joy:

@darkbrain85 sagte in Systemlast bei Nutzung von InfluxDB:

ich bin halt ein Datenmessie...

ich auch - hatte etwa 400 Datenpunkte teilweise im Sekundentakt geloggt und entsprechend groß waren die Verzeichnisse

Aber es lief absolut problemlos, da das Tinkerboard ein Dual-Channel DDR4-RAM besaß
(Das Ganze ging übrigens auf µSD-Karte :rolling_on_the_floor_laughing: )

[darkbrain85]

Diese Diskussion (Eiervergleich) führt ja so zu nichts.

Klar läuft das alles wie es soll, aber ich hätte gerne mehr Dampf auf dem Kessel.
Vor allem aber auch, weil halt eine stark ausgelastete CPU halt in meinem Fall auch andere VM's beeinflusst.

Ich meine, mein in die Jahre gekommener Server wird wohl noch locker schneller als ein Tinkerboard sein.

Ich schimpfe auch über mein relativ hochwertiges Firmennotebook weil es zu langsam ist. Einfach weil ich Privat ein dickes (dünnes) Eisen(Alu) mit einem Apfel drauf nutze und da einfach anderes gewohnt bin.

So hat jeder seine persönlichen Anforderungen.

[Homoran]

@darkbrain85 sagte in Systemlast bei Nutzung von InfluxDB:

Diese Diskussion (Eiervergleich) führt ja so zu nichts.

Das passt jetzt gar nicht!!

Es geht darum die Ursache für die Belastung zu finden, sonst ist der nächstgrößere Rechner auch bald am Anschlag.
Der Vergleich diente dazu zu zeigen, dass da etwas nicht stimmt!

@darkbrain85 sagte in Systemlast bei Nutzung von InfluxDB:

So hat jeder seine persönlichen Anforderungen.

Das ist eine ganz andere Ebene.

@darkbrain85 sagte in Systemlast bei Nutzung von InfluxDB:

mein in die Jahre gekommener Server wird wohl noch locker schneller als ein Tinkerboard sein.

EBEN!
und trotzdem nicht ausreichend? - da stimmt dann IMHO was nicht

[A Former User]

@darkbrain85 Hast du die Daten in InfluxDB über mehrere Jahre gespeichert?
Heisser Tipp: Du kannst sehr einfach die Daten Aggregieren in Influx mittels Continuous Queries (https://docs.influxdata.com/influxdb/v1.7/query_language/continuous_queries/)
Wenn du die Datenmenge für deine Abfrage stark minimieren kannst, dann sollte dies sehr schnell positiv auf die CPU aich auswirken..

Ansonsten poste mal bitte ein paar Details zu deiner Influx.
Anzahl Speicher Gesamt?
Anzahl Messpunkte, Datenpunkte?
Typische Abfrage Zeiträume?

Dann lässt sich dein Problem leichter nachvollziehen

[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!!