Monatsrückblick Juli / August 2026 ist online!

[OliverIO]

@Homoran sagte:

Nein, die sind nur höchstens alkec6 Sekunden.

hm, du siehst allein in dem kleinen ausschnitt den ich beispielhaft gepostet habe ist mehrfach
system.host.ioBrokerpi5.freemem
Messwerte.0.HardwareDaten.Master.Speicher.mem_free
Messwerte.0.HardwareDaten.Master.Speicher.memBuffered
alles in der gleichen sekunde enthalten.
der exakte trigger lässt sich nicht ermitteln, da ja einmal der history adapter wegen schreiben liest und aber auch deine diagramme (womöglich in mehreren diagrammen den gleichen datenpunkt mehrfach) ebenfalls lesen.
aber alle fragen die history adapter funktionalität

ich will es nur nochmal erwähnen. eine datenbank für die history werte würde das wahrscheinlich entschärfen.

aber jetzt schauen wir mal auf die nächsten snapshots bevor man vorschnell entscheidungen trifft. passe erst mal auch NICHT den history intervall deiner datenpunkte an, sonst ist ggfs die grundlage der analyse weg um entscheiden zu können.

[paul53]

@Homoran [sagte]: Unter top tauchte ab und zu ei prozess "node" auf und verschwand sofort wieder

Das passiert immer dann, wenn "node" einen neuen Prozess (Instanz / Skript) compiliert und startet.

[OliverIO]

@paul53 @homoran

der Ausschnitt ist aus dem Abschnitt
===== PROCESSES WITH MOST THREADS =====

Ich denke threads sieht man unter top nicht.

[Homoran]

@OliverIO sagte:

hm, du siehst allein in dem kleinen ausschnitt den ich beispielhaft gepostet habe ist mehrfach
system.host.ioBrokerpi5.freemem
Messwerte.0.HardwareDaten.Master.Speicher.mem_free
Messwerte.0.HardwareDaten.Master.Speicher.memBuffered

Die rufe ich per 15sec. Cron und dann mit exec ab.

Wo die mehrfach pro sekunde herkommen ist mir schleierhaft

Edit:
Lesen in der history ist möglich.
Könnte das beim zoomen passieren....

...oder eventuell bei mehrfachem Einlesen, weil der Browser Kontakt verliert
Auch die sockets wurden mehrfach pro sekunde neu verbunden

[OliverIO]

@Homoran

ich weiß nicht wie die diagramme auf aktualisierung der datenpunkte reagieren.
zu vermuten ist, das wenn sich der datenpunkt ändert, das diagramm die history abruft. wenn der datenpunkt in mehreren diagrammen auftaucht, dann sind das auch verschiedene lesevorgänge.

[Homoran]

@OliverIO sagte:

ich weiß nicht wie die diagramme auf aktualisierung der datenpunkte reagieren.
zu vermuten ist, das wenn sich der datenpunkt ändert, das diagramm die history abruft. wenn der datenpunkt in mehreren diagrammen auftaucht, dann sind das auch verschiedene lesevorgänge

Jein!
Du kannst in den charts einen Zeitraum für den refresh einstellen.

Natürlich wird beim neuladen/zoomen auch neu abgerufen, weil auch anders aggregiert wird.
Das hat immer schon zu mehr Last geführt.
Bei sehr komplexen Charts und mehreren Zoomversuchen am Tablet/Handy ist es auch früher mal!! zum Absturz gekommen.
Aber vielleicht 2x im Jahr!

Im Moment spiele ich natürlich viel an den Charts, um Zusammenhänge zu sehen.
Das lenkt dann vielleicht vom eigentlichen Problem ab.
Da sollten wir nur Drops beachten, die nachts passieren.

Hier die letzten 3 ganz großen Snapshots
snapshot_20260831_162341.log snapshot_20260831_162442.log snapshot_20260831_163935.log

[OliverIO]

@Homoran

• memory.log
  noch bitte

[Homoran]

@OliverIO hier
1853memory.log

[OliverIO]

@Homoran

also mit meiner Vermutung lag ich richtig.
hier die Analyse.
Ich habe dem codex nichts von dem was ich vorhin geschrieben habe mitgeteilt. einfach nur hier neue dateien.

hast du mehrere browserclients laufen?
jeder fragt natürlich auch wieder separat ab und löst eine neue getHistory aus.

Folgeanalyse der memwatch-Daten vom 31.08.2026

Kurzfazit

Die neuen Snapshots identifizieren den Verursacher der Task- und
Speicherstürme eindeutig:

io.history.0 (PID 39891) startet gleichzeitig sehr viele separate
Node-Prozesse mit iobroker.history/build/lib/getHistory.js.

Jeder dieser Prozesse besitzt typischerweise sieben Threads und ungefähr
40 bis 57 MB RSS. Bei 76 bis 156 gleichzeitig aktiven getHistory.js-Prozessen
entstehen deshalb innerhalb weniger Sekunden mehrere hundert bis über tausend
zusätzliche Tasks und ein Speicherbedarf von mehreren Gigabyte. Im zweiten
Snapshot sind zusätzlich 112 nicht abgeholte Zombie-Prozesse ([node] <defunct>) sichtbar.

Der zuvor verdächtigte Adapter dwd.0 ist damit als Hauptursache widerlegt.
Die unmittelbare technische Ursache liegt im History-Adapter beziehungsweise
in einer extrem hohen Zahl paralleler History-Abfragen. Welcher Client oder
welches ioBroker-Script diese Abfragen auslöst, lässt sich aus den gelieferten
System-Snapshots allein noch nicht endgültig bestimmen.

Ausgewertete neue Dateien

• 1788195273188-1853memory.log
• 1788190003254-snapshot_20260831_162341.log
• 1788190003258-snapshot_20260831_162442.log
• 1788190003266-snapshot_20260831_163935.log

Das große memory.log enthält zahlreiche weitere Trigger. Für drei Ereignisse
wurden detaillierte Snapshots mitgeliefert; diese drei erlauben die eindeutige
Prozesszuordnung.

Übersicht der drei detaillierten Ereignisse

Snapshotzeit	MemAvailable-Abfall	Taskanstieg	Tasks am Trigger	aktive getHistory.js	Zombies	Threads der aktiven History-Children
16:23:42	1.859 MB	+955	1.669	156	0	1.092
16:24:43	1.103 MB	+525	1.239	76	112	532
16:39:36	1.283 MB	+829	1.487	141	3	987

Die Zahlen passen sehr genau zusammen: 156 aktive Child-Prozesse mit jeweils
sieben Threads ergeben 1.092 Threads. Zusammen mit den ungefähr 700 normalen
Systemtasks erklärt das vollständig die am Trigger beziehungsweise unmittelbar
danach beobachtete Größenordnung.

Eindeutige Parent-Zuordnung

In allen drei Soforterfassungen ist der Parent der massenhaft erzeugten
Prozesse:

PID 39891  io.history.0

Beispiele seiner Children sehen so aus:

/usr/bin/node --max-old-space-size=1700 \
  /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {...}

Die Parent-Gruppierung ergibt:

• um 16:23:42: 156 Prozesse mit PPID 39891,
• um 16:24:43: 188 Prozesse mit PPID 39891,
• um 16:39:36: 144 Prozesse mit PPID 39891.

Beim mittleren Snapshot bestehen diese 188 Children aus 76 noch aktiven
getHistory.js-Prozessen und 112 Zombies. Das beweist auch, dass der
History-Prozess zu diesem Zeitpunkt beendete Child-Prozesse nicht schnell genug
mit wait() beziehungsweise über seinen Child-Exit-Handler aufgeräumt hatte.

Speicherwirkung

Die aufsummierten RSS-Werte der aktiven getHistory.js-Prozesse betragen in den
drei Soforterfassungen rechnerisch ungefähr:

• 8.171 MB bei 156 aktiven Prozessen,
• 3.828 MB bei 76 aktiven Prozessen,
• 7.094 MB bei 141 aktiven Prozessen.

Diese RSS-Summen dürfen wegen gemeinsam genutzter Speicherseiten nicht als
exakter physischer RAM-Verbrauch interpretiert werden. Die gleichzeitig
gemessenen realen Einbrüche von MemAvailable um 1,1 bis 1,9 GB zeigen aber,
dass ein großer privater Speicheranteil tatsächlich angelegt wird. Die
Parallelität reicht auf dem 8-GB-System aus, um die früher beobachteten
OOM-Ereignisse zu erklären.

Jeder Child-Prozess darf außerdem mit folgendem Parameter theoretisch einen
sehr großen Node-Heap anlegen:

--max-old-space-size=1700

Ein einzelner Prozess nutzt dieses Maximum hier nicht aus. Bei über hundert
gleichzeitigen Prozessen ist diese Konfiguration jedoch keine wirksame
Gesamtbegrenzung.

Muster der History-Abfragen

Es handelt sich nicht um einzelne, sehr große Abfragen, sondern um viele
parallel wiederholte Abfragen. Typische Parameter sind:

{
  "count": 1500,
  "aggregate": "minmax",
  "limit": 1500,
  "start": 1788127200000,
  "end": 1788213600000
}

Mehrere identische Datenpunkte werden gleichzeitig oder in rasch aufeinander
folgenden Sessions wiederholt abgefragt. Beispiele aus den Snapshots:

• system.host.ioBrokerpi5.freemem
• system.host.ioBrokerpi5.inputCount
• system.host.ioBrokerpi5.outputCount
• system.host.ioBrokerpi5.load
• system.adapter.javascript.1.inputCount
• system.adapter.javascript.1.outputCount
• Messwerte.0.HardwareDaten.Master.CPU_Last.CPU_Temp
• Messwerte.0.Solaranlage.Momentanwerte.Solarestimate2
• Messwerte.0.Solaranlage.Momentanwerte.Leistung_AC_aktuell
• Messwerte.0.Solaranlage.Momentanwerte.Eigenverbrauch
• Messwerte.0.Stromzaehler.Momentanwerte.akt_Verbrauch
• Messwerte.0.Stromzaehler.Momentanwerte.akt_Einspeisung
• Messwerte.0.Batterie.Ladung
• Messwerte.0.Batterie.Entladung
• alias.0.Stromzaehler.Bezug_aktuell
• modbus.1.inputRegisters.226.789_Solar_PV_power

Im Snapshot um 16:39 werden beispielsweise sieben System-/Hardware-Datenpunkte
jeweils ungefähr 19- bis 20-mal parallel angefragt. In den Prozessargumenten
steigen dabei auch die sessionId-Werte fortlaufend an. Das sieht nach
wiederholten Anfragegruppen eines Dashboards, Diagramms oder Scripts aus und
nicht nach einer normalen Einzelabfrage.

Ursache und Auslöser getrennt betrachtet

Technische Ursache: bestätigt

Der History-Adapter erzeugt für jede History-Abfrage einen eigenen
getHistory.js-Child-Prozess. Zu viele gleichzeitige Abfragen führen direkt zu:

• hunderten Node-Prozessen,
• sieben Threads pro aktivem Prozess,
• massiv steigenden PageTables und KernelStack,
• mehreren Gigabyte zusätzlichem Speicherbedarf,
• kurzzeitig hoher CPU- und I/O-Last,
• Zombies, wenn Children schneller enden als sie abgeholt werden,
• im Extremfall OOM-Kills.

Anfragender Client: noch nicht abschließend identifiziert

PPID 39891 beweist, dass io.history.0 die Prozesse startet. Die Argumente der
Children enthalten jedoch nicht den Namen des Clients, der die History-Anfrage
an den Adapter geschickt hat. Wahrscheinliche Quellen sind:

1. ein geöffnetes VIS-/VIS-2-Dashboard mit vielen oder zyklisch neu gerenderten
   Diagrammen,
2. ein Flot-/ECharts-/Chart-Widget mit zu kurzem Refresh-Intervall,
3. ein JavaScript unter javascript.1, das viele getHistory-Aufrufe startet,
   ohne deren Abschluss abzuwarten,
4. eine Schleife oder ein mehrfach registrierter Timer/Listener, der dieselben
   Abfragegruppen immer wieder startet.

Die Datenpunktgruppen wirken wie Dashboard- oder Energievisualisierungsdaten.
Das ist ein starker Hinweis, aber noch kein Beweis für einen bestimmten Client.

Korrektur der vorherigen Bewertung

In der ersten Analyse war dwd.0 aufgrund seines Startzeitpunkts der stärkste
damals sichtbare Verdächtige. Die frühere Threadliste kam zu spät und war zudem
teilweise leer. Die reparierte Soforterfassung zeigt nun den tatsächlichen
Mechanismus. dwd.0 erklärt die neuen Peaks nicht; seine zeitliche Nähe im
früheren Snapshot war eine Korrelation ohne Kausalitätsnachweis.

Dringend empfohlene Maßnahmen

1. System kurzfristig stabilisieren

• Betroffene Visualisierung beziehungsweise das verdächtige Script schließen
  oder deaktivieren.
• Falls der Sturm gerade läuft, io.history.0 kontrolliert neu starten, damit
  aktive Children und Zombies verschwinden.
• Danach beobachten, ob die Taskzahl wieder stabil bei ungefähr 650 bis 720
  bleibt.

Ein Neustart behandelt nur die Symptome. Ohne Beseitigung des Anfrageerzeugers
wird der Sturm erneut auftreten.

2. Anfragequelle per A/B-Test ermitteln

In dieser Reihenfolge jeweils nur eine Änderung vornehmen und memory.log
beobachten:

1. Alle Browser mit ioBroker-Visualisierungen schließen.
2. Falls die Peaks aufhören, Browser/Views einzeln wieder öffnen.
3. Falls sie weiterlaufen, verdächtige JavaScript-Instanz beziehungsweise
   einzelne Scripts deaktivieren.
4. Besonders nach Scripts suchen, die sendTo('history.0', 'getHistory', ...),
   getHistory(...) oder periodische Chart-Aktualisierungen verwenden.
5. Timer, setInterval, State-Subscriptions und rekursive Aktualisierungen
   darauf prüfen, ob bei jedem Lauf neue Abfragen gestartet werden, bevor alte
   abgeschlossen sind.

3. Parallelität begrenzen

Beim eigentlichen Aufrufer sollten History-Abfragen:

• nicht mehrfach parallel für denselben Datenpunkt laufen,
• erst nach Abschluss der vorherigen Anfrage erneut gestartet werden,
• in einer begrenzten Queue verarbeitet werden,
• gecacht oder zusammengefasst werden,
• mit einem deutlich längeren Aktualisierungsintervall laufen.

Schon eine Begrenzung auf wenige gleichzeitige Abfragen würde den Task- und
Speicherpeak drastisch reduzieren.

4. History-Adapter prüfen und aktualisieren

• Installierte Version von iobroker.history feststellen.
• Changelog und bekannte Probleme dieser konkreten Version bezüglich
  getHistory.js, Child-Prozessen, Parallelität und Zombies prüfen.
• Ein Update erst nach Versions- und Kompatibilitätsprüfung durchführen.

Die Systemdaten belegen eine problematische Last, sagen aber nicht, ob die
eingesetzte Adapterversion bereits eine eingebaute Parallelitätsbegrenzung
anbietet oder ob es dazu einen bekannten Fix gibt.

Sinnvolle Zusatzdiagnose

Für die eindeutige Identifikation des anfragenden Clients sollten unmittelbar
um einen Peak zusätzlich gesichert werden:

iobroker logs --watch

und gezielt:

grep -RniE "getHistory|sendTo.*history\.0|history\.0.*getHistory" \
  /opt/iobroker/iobroker-data/files \
  /opt/iobroker/node_modules 2>/dev/null

Bei JavaScript-Quelltexten sollte bevorzugt über die ioBroker-Objekte oder den
Admin exportiert/gesucht werden, weil nicht jedes Script als normale Datei
vorliegt.

Zusätzlich wäre eine kurze Liste der geöffneten VIS-Views und der aktiven
Chart-Widgets zum Peakzeitpunkt hilfreich. Die im Prozessargument sichtbaren
sessionId-Gruppen könnten dann einer konkreten Browser-/Widget-Sitzung
zugeordnet werden, sofern der Adapter im Debug-Log die Session protokolliert.

Endergebnis

Die Diagnose ist jetzt wesentlich belastbarer als zuvor. Es handelt sich nicht
um einen einzelnen Node-Prozess mit tausenden Threads, sondern um einen
Prozesssturm aus bis zu 156 gleichzeitig aktiven getHistory.js-Prozessen.
Diese werden alle von io.history.0 erzeugt und besitzen jeweils sieben
Threads. Wiederholte parallele History-Anfragegruppen sind damit die bestätigte
Ursache für die Task-, PageTable-, KernelStack- und RAM-Spitzen.

Der nächste Untersuchungsschritt sollte nicht mehr allgemein nach einem
Speicherleck suchen, sondern gezielt den Client beziehungsweise das Script
finden, das diese History-Abfragen in hoher Parallelität auslöst.

[Homoran]

@OliverIO sagte:

sondern gezielt den Client beziehungsweise das Script
finden, das diese History-Abfragen in hoher Parallelität auslöst.

Üblicherweise ist das ein Client.

Deswegen irritiert mich das so.
Das hat jahrelang so funktioniert.
Außerdem:

@OliverIO sagte:

system.host.ioBrokerpi5.freemem
system.host.ioBrokerpi5.inputCount

system.adapter.javascript.1.inputCount
system.adapter.javascript.1.outputCount

Sind erst nach dem Auftreten der Probleme hinzugekommen!

@OliverIO sagte:

jeweils ungefähr 19- bis 20-mal parallel angefragt

Dafür habe ich keine Erklärung

Auch nicht dass der Absturz üblicherweise stattfindet wenn kein client aktiv ist.

Wie ich ganz zu Beginn schon zeigte

Verbindet/trennt sich der client (...116, das ist mein Tablet) auch mehrfach pro Sekunde.
Das wäre vielleicht die Ursache der im log festgehaltenen Phänomene, ohne dass das die wirklichen Ursachen sind.

Ich bin ratlos

[OliverIO]

@Homoran

um clients dann ausschließen mal eine weile alle browser tabs auf allen geräten mit iobroker schließen und schauen ob diese große Anzahl an threads noch auftauchen.

du nutzt vis1 oder vis2 als visualisierung?

dann auch mal PC browser und tablet vergleichen. also nur PC browser geöffnet und tablet nicht und umgekehrt.
Nicht das bspw das tablet ständig in schlafmodus geht und gleich wieder aufwacht. das löst evtl auch eine aktualisierung aus.
jeder einzelne tab zählt auch als separater client

[Homoran]

@OliverIO sagte:

um clients dann ausschließen mal eine weile alle browser tabs auf allen geräten mit iobroker schließen und schauen ob diese große Anzahl an threads noch auftauchen

Mach ich, aber nicht sofort.
Erst nach dem nächsten Absturz.

Dazu eine Verständnisfrage:

• Werden alle views eines Projekts beim öffnen von vis im Hintergrund geladen?
• werden alle Tabs eines Browsers beim öffnen des Browsers im Hintergrund geladen?

Üblicherweise öffne ich zwei views in denen kein oder drei charts sind.
Nur bei Nachfragen öffne ich Detailseiten mit charts.

Jetzt während der Gehletsuche halte ich 3-5 weitere Tabs mit je einem flotchart vor. Öffnen nur bei bedarf.

Die genannten Datenpunkte kommen dort vor!

Ich hatte auch schon an das letzte Update des Browsers als Ursache gedacht.

Erklärt aber alles einen Absturz während der Ruhezeit nicht!

@OliverIO sagte:

du nutzt vis1

@OliverIO sagte:

nur PC browser

Isch 'abe kein pezeh!
Nur Täblett

@OliverIO sagte:

jeder einzelne tab zählt auch als separater client

Ok!
Siehe oben

DANKE!

[arteck]

@Homoran sagte:

Werden alle views eines Projekts beim öffnen von vis im Hintergrund geladen?

des Projektes ja... hast du 20 Projekte dann nur das was du lädts. wobei iframes erst dann wenn du es auf die sichtbare Seite umswitcht

@Homoran werden alle Tabs eines Browsers beim öffnen des Browsers im Hintergrund geladen?

das ist problematisch.. manche Browser ja manche nöö. es gibt plugins die das verhindern . genauso wie auch refresh alles IMMER

@Homoran sagte:

Nur Täblett

was den apfel ??

[Homoran]

@arteck sagte:

wobei iframes erst dann wenn du es auf die sichtbare Seite umswitcht

Also nein!
Die belasten getHistory nicht.

@arteck sagte:

manche Browser

Gut dann wechsel ich nach dem nächsten Crash den Browser

@arteck sagte:

was den apfel ??

Nöö robot

[OliverIO]

@Homoran

ja alle views werden gleichzeitig geladen.
die ausgeblendeten views sind bspw div elemente mit hidden.

der browser verhindet normalerweise javascript in nicht aktiven tabs,
daher gibt es meist ein reload, wenn man den tab wieder aktiviert.
gibt da zwar auch eine möglichkeiten mit einem worker script, keine ahnung ob das in vis1/2 zur Anwendung kommt.

wie sich das mit einem aktiven tab und charts in nicht sichtbaren views verhält weiß ich nicht.

welchen diagram adapter nutzt du? flot?
da gibts kein worker, allerdings fragt er direkt gethistory ab

[OliverIO]

@Homoran sagte:

Die belasten getHistory nicht.

hm, eigentlich schon. iframe ist ja nur ein guckfenster auf eine html seite.
da werden auch javascripts geladen und machen alles was da drin steht.
also siehe oben. auch getHistory wird da aufgerufen.

[arteck]

@OliverIO sagte:

also siehe oben. auch getHistory wird da aufgerufen.

ja aber nur wenn du die View Seite öffnest.. nicht im Hintergrund

wenn du im Projekt 4 Seiten hast auf seite 2 ein iframe und du die die Seite 1 als Standard nimmst
dann wird das Iframe nicht direkt geladen sondern erst wenn du auf die Seite 2 wechselst

[OliverIO]

@arteck
Den Post davor, bitte auch noch im Kontext lesen

[Homoran]

Bin nur kurz zu Hause, hab heute seit früh einige Arzttermine.

Natürlich ist er heute Nacht abgestürzt. Hab noch keine genaue Informationen gesammelt - mache ich später!

Nur bitte eins vorweg.
Ich glaube ja, was die KI aus den Daten herausliest, keine Frage.
Aber ich halte das nicht für die Ursache, nur für einen Auslöser.
Das selbe wird auch früher gewesen sein, aber nicht so heftig!

Mittlerweile habe ich so viel an logs und logdaten zurückgeschraubt, dass wir von daher bestimmt ein Jahr zurückliegen.
Und damals hat genau das selbe Vorgehen keinen Absturz verursacht.

Wenn ich jetzt hier nach der load sehe

Und alles ist gut.

...und ich mir dann den Verlauf ansehe

...und auch hier ist alles wunderbar.

Und ich dann zurück zu den gauges gehe, fängt jetzt die load an (tlw. eine Stunde bis zum Anschlag und zurück zu tanzen.

Das war früher definitif nicht so!!

(Achtung Beispielbilder für die views. Inhaltlich nicht passend!
Sollte nur zeigen, dass duese views eigentlich nicht die von der KI als Hauptursache genannten DPs enthält)

Außerdem ergibt die Aussage

um einen
Prozesssturm aus bis zu 156 gleichzeitig aktiven getHistory.js-Prozessen.
Diese werden alle von io.history.0 erzeugt und besitzen jeweils sieben Threads

Für mich keinen Sinn dass alle Prozesse genau sieben Threads besitzen sollen

Wenn es kein iobroker Update war, das dieses Phänomen jetzt verursacht könnte es ja auch eine Änderung im OS sein, hier gab es letzte Zeit diverse updates incl. Kernel.
(Z.B.: Möglicherweise ist der große, immer mehr genutzte, Swap ein Punkt, wenn die load eh schon hochgeht und dann 1GB ausgelagert werden soll klemmt's noch mehr)
Einen kompletten reboot hab ich noch nicht gemacht, damit ich das journal nicht zurücksetze.
Oder im nodejs. Da kann ich gar nix zu sagen.
Ich könnte ja mal auf nodejs v24 gehen.

Und die aussage der KI, dass der controller möglicherweise nur als Kollateralschaden beim oom-reaper herhalten muss, lässt mich auch denken.

Bitte bedenkt dies bei weiteren Bewertungen der Auswertungen.

Ich werde hoffentlich zeitnah Daten vom Absturz liefern können.

[Homoran]

Mal quick&dirty!
Aktuell!

Absturz

Daten
snapshot_20260831_221940.log snapshot_20260831_221750.log
snapshot_20260831_221732.log
09011417memory.zip

Memory.log musste ich zippen, ging so st nicht hier rein.

Fehlt noch was?

Wenn ich wieder etwas mehr Zeit hab

Kann ich experimentieren