Nächtlicher Systemabsturz

[Thomas Braun]

@bloop sagte in Nächtlicher Systemabsturz:

Operating System: Ubuntu 21.10

Längst tot und begraben. Installier da was lebendiges, bevorzugt das aktuelle Debian Stable Release.

[Neuschwansteini]

@bloop

Und sei so gut, gib dem System mehr RAM, wenn da unbedingt Influx auch noch drauf sein mus.. ich würde das in einen extra Container auslagern..

[bloop]

@thomas-braun Herzlichen Dank für die Info! Ich muss ehrlichgestehen nachdem das System selbst immer stabil lief hab ich mir nie wirklich einen Kopf darum gemacht. Denke dann werde ich demnächst auf ein anderes Betriebssystem umsteigen.
Allerdings denke ich nicht das mein Problem daher kommt

[bloop]

@ilovegym Die InfluxDbs laufen in eigenen Container.
Auf diesem läuft ausschließlich der Broker

[OliverIO]

@bloop

Kann es sein das der Rechner auch ganz gut ausgelastet ist?
Wenn ich das so überschlage bei 75-90%?
Load avg / Anzahl threads = 3 bis 3.6 / 4

[Thomas Braun]

@bloop sagte in Nächtlicher Systemabsturz:

Allerdings denke ich nicht das mein Problem daher kommt

Schau ich mir auf der Basis aber auch nicht weiter an.

[Marc Berg]

@bloop sagte in Nächtlicher Systemabsturz:

Die InfluxDbs laufen in eigenen Container.

These: Die InfluxDBs sind so fett geworden, dass sie bei internen Reorganisationsläufen den gesamten RAM auffressen und die Festplatte lahm legen. Das lässt auch den ioBroker abschmieren.

Lösung: Datenbanken deutlich abspecken oder potentere HW nutzen.

[bloop]

@oliverio
Gute Frage weshalb der Log eine so hohe Auslastung anzeigt.
Dies hat sich scheinbar jetzt aber beruhigt.

Systemuptime and Load:
 10:20:31 up 14:40,  1 user,  load average: 1.69, 1.78, 1.77
CPU threads: 4

Der PVE hat eine Gesamtauslastung von 28% und einen durchschnittlichen Auslastung von 0.26,0.87,1.38

[bloop]

@marc-berg
Herzlichen Dank!
Einen ähnlichen Gedanken hatte ich auch schon.
Die LXC mit der InfluxDB hat sich aber erst nach 05:00 gefüllt.

Bereits vorher hat der ioBroker die Instanzen neu gestartet.
Hier muss etwas mit der Verbindung nicht gepasst haben. Was schlussendlich zum Systemabsturz führte.

Ich habe nun die influxdb Instanz auf Logstufe Debug gestellt, eventuell lässt sich etwas finden.

[A Former User]

@bloop said in Nächtlicher Systemabsturz:

2024-10-03 19:54:33.269 - info: influxdb.2 (1029) Store 25144 buffered influxDB history points
2024-10-03 19:54:33.269 - info: influxdb.2 (1029) Too many data points (25144) to write at once; write per ID

Warum hast Du denn da überhaupt 2 Instanzen laufen und bei der 2.ten sammelst Du so viele
Daten im Ram, dass der Adapter die nicht mehr auf einmal schreiben kann.
Mach doch mal ein kleineres Schreibintervall.
Zeig mal Deine DB Settings von der Instanz und wozu noch mariadb?

Wenn da Nachts noch backitup dazukommt, wird es schwarz am Bildschirm.

[bloop]

@rscsb

Warum hast Du denn da überhaupt 2 Instanzen laufen und bei der 2.ten sammelst Du so viele
Daten im Ram, dass der Adapter die nicht mehr auf einmal schreiben kann.

Mein System musste mit der Zeit immer mehr erweitert werden. Anfangs nur mit MariaDB mit dem Umstieg auf Grafana dann die InfluxDB 1.8 (influxdb.1). Nachdem ich damit aber keine monatliche bzw. jährlichen Summierungen in Grafana machen konnte, bin ich dann auf InfluxDb 2 (influxdb.2) umgestiegen.

MariaDB läuft noch wegen 3-5 Datenpunkten. Weils für mich einfacher war vergangene Werte im Skripts abzurufen.
Auf InfluxDB 1.8 nimmt das aufzeichnen stetig ab und ich steige auf die 2er Version um. Ich möchte aber weiterhin auf viele in 1.8 abgelegte Daten über Grafana zugreifen.

Mach doch mal ein kleineres Schreibintervall.

Der Schreibintervall ist auf Standard 600sek
Beim Öffnen der Einstellungen ist mir aufgefallen das es an dieser Einstellung liegen könnte:

Wenn ich das richtig verstehe, schreibt er den letzten Wert. Ich glaube er schreibt dann nicht nur diese Werte, sondern alle vorherigen welche nicht in der Datenbank abgelegt werden konnten. Diese bleiben im Ram hängen. Nach dem Neustart, erst am Abend, ergab dies die unglaubliche Zahl von 25144 Datenpunkten welche nicht in die Datenbank geschrieben werden konnten.
Ich habe den Hacken jetzt raus genommen und hoffe es kommt nicht erneut vor.

Wenn da Nachts noch backitup dazukommt, wird es schwarz am Bildschirm.

Das Backup findet um 1:30 statt. Zwischen beginn der Ram Auslastung und dem Backup lagen 3std

Bis 4:30 früh sieht alles völlig normal aus.

[A Former User]

@bloop

Schluck...Beim Beschreiben Deiner Umgebung merkst Du bestimmt auch was Du da alles "aufgebaut" hast.
Eine Migration von Influxdb wäre wahrscheinlich sinnvoller gewesen.
Was auf Deinen Containern passiert, weißt wohl nur Du.

Dass dieser deaktivierte Hacken an dem Problem etwas verändert bezweifle ich.
Ich habe den aktiviert, weil es wohl "Standard" ist.
Was hast Du bei "Schreibaktionen zusammenfassen" drin.
(Mit Screenshot müsste man nicht jeden Parameter abfragen)

Was ich seltsam an Deiner Installation finde, ist, dass Du die Verbindung zu Deinen States/Objects mit Deiner IP-Adresse (192.168.0.110) konfiguriert hast.
Normal wäre doch meiner Meinung 127.0.0.1 bzw. 0.0.0.0.
Um 04:34 Uhr bricht die Hölle los in IO/CPU und der Traffic fällt ab,
soweit, dass ioBroker sogar die Verbindung zur eigenen DB verliert.
Was zuerst in welcher Reihenfolge eintritt, musst Du Dir morgen früh mal anschauen.

[bloop]

@rscsb
Danke für deine Unterstüttzung!
Eine Migration wäre im Nachhinein sicher besser gewesen. Anfangs kam dies jedoch nicht in Frage, da ich mir mir Flux echt schwer getan habe. Zudem wären über 20 Diagramme zu überarbeiten gewesen.
So nehm ich mir immer wieder einmal ein Diagramm vor und überarbeite alles.
Heute würde ich das auch nicht mehr so machen ^^

Dass dieser deaktivierte Hacken an dem Problem etwas verändert bezweifle ich.
Ich habe den aktiviert, weil es wohl "Standard" ist.
Was hast Du bei "Schreibaktionen zusammenfassen" drin.
(Mit Screenshot müsste man nicht jeden Parameter abfragen)

Ebenfalls Standard Einstellung.

Was ich seltsam an Deiner Installation finde, ist, dass Du die Verbindung zu Deinen States/Objects mit Deiner IP-Adresse (192.168.0.110) konfiguriert hast.
Normal wäre doch meiner Meinung 127.0.0.1 bzw. 0.0.0.0.

Auch in den Host Einstellungen habe ich nie etwas verändert.
Wie ist diese bei dir eingestellt?

These: Wenn der IoBroker die Datenbank auf der IPAdresse 192.168.0.110 "sucht". Es aber zu einem Problem beim Router kam, ließe sich mein Phänomen eventuell erklären?
Wäre durch umstellen auf 127.0.0.1 dies dann behoben?

[A Former User]

@bloop said in Nächtlicher Systemabsturz:

Zudem wären über 20 Diagramme zu überarbeiten gewesen.

Hmm, wie einige habe ich auch von influxdb_v1 auf influxdb_v2 migriert, habe aber kein einziges Diagramm angepasst. (Dies aber nur am Rande)

Deine DB Settings sehen "normal" aus.

Bei den ioBroker Settings benutzt er bei mir die Loopbackadresse und nicht das Netzwerkinterface:

Ich denke, dass, wie schon von Marc Berg geschrieben, in Deinem InfluxDB_V2 Container etwas krankt. Der ioBroker bekommt die Zahlen nicht abgeliefert und läuft aus dem RAM.
"Irgendwann" spukt etwas auf Dein Netzwerkinterface, worauf der ioBroker seine Verbindung zu der internen JSON-DB verliert. So könnte ich mir die Kettenreaktion denken...

An diesen zwei Stellen würde ich mal nachforschen.

[Marc Berg]

@bloop sagte in Nächtlicher Systemabsturz:

Die LXC mit der InfluxDB hat sich aber erst nach 05:00 gefüllt.

Gibt's auch eine Kurve für die Festplattennutzung?

[bloop]

@marc-berg sagte in Nächtlicher Systemabsturz:

@bloop sagte in Nächtlicher Systemabsturz:

Die LXC mit der InfluxDB hat sich aber erst nach 05:00 gefüllt.

Gibt's auch eine Kurve für die Festplattennutzung?

Nichts wirklich brauchbares.

Die Belastung scheint völlig normal zu sein.
Ab 5:34 bricht jedoch die Aufzeichnung bis zum Neustart ab. Die angezeigten Daten kommen nicht aus iobroker sondern direkt aus Proxmox.