Monatsrückblick Juli / August 2026 ist online!

[OliverIO]

@Homoran

wieder die bisherigen logdateien löschen und dann

den service neu starten

  sudo chmod +x /usr/local/sbin/memwatch.sh
  sudo systemctl restart memwatch.service
  systemctl status memwatch.service

openai ist wohl gerade überlastet. konnte die dateien über chatgpt nicht hochladen. musste zu codex cli lokal wechseln

[Homoran]

@OliverIO sagte:

leider mit noch nicht ganz so eindeutigen hinweisen.

Ich hätte jetzt was neues für dich
Die snapshots kommen im minutentakt

snapshot_20260831_153941.log snapshot_20260831_153921.log snapshot_20260831_153841.log snapshot_20260831_153541.log snapshot_20260831_153440.log snapshot_20260831_153339.log snapshot_20260831_153309.log snapshot_20260831_153240.log snapshot_20260831_153140.log snapshot_20260831_153040.log 1540memory.log

Ich sehe mir jetzt sofort deine Vorschläge an

[Homoran]

So,
Neues Programm läuft!

Dwd.0 hat wohl Probleme mit der gesicherten Verbindung.
Das hatte das log zugespammt.

Ich glaube da wurde nur das logging deaktiviert.

Dwd ist scheduled, daher due Aussage "direkt nach dem start...."

[Homoran]

Ich will nicht zu viel schicken!
Hier mit neuem Programm und hoher load

Hier ist grün die load!!
Bis zum Anschlag

Und logs noch und nöcher
snapshot_20260831_160141.log snapshot_20260831_160241.log snapshot_20260831_160346.log snapshot_20260831_160451.log snapshot_20260831_160542.log snapshot_20260831_155944.log

1606memory.log

Ich würde erst wieder etwas senden, wenn deine KI mehr Informationen braucht oder der iob gekillt wurde

*DANKE!!K

[OliverIO]

@Homoran

da war jetzt nur das um 1605 mit dem neuen skript von den snapshots.
wir sammeln noch ein wenig.
gut, der höher load kommt nun auch ein wenig von dem skript

ohne bisher die ki zu fragen ist mir aber an den letzten snapshots bspw beim
1788185456278-snapshot_20260831_153339.log
folgendes aufgefallen

 285056   39891 iobroker    7  0.6 49664 751040 Sl   Mon Aug 31 15:33:37 2026 node            /usr/bin/node --max-old-space-size=1700 /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {"id":"system.host.ioBrokerpi5.freemem","path":"/mnt/usbplatte/data/history/","start":1788161558739,"end":1788183158739,"count":300,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"min","limit":300,"addId":false,"sessionId":1056,"returnNewestEntries":false,"integralInterpolation":null,"removeBorderValues":false,"logId":"alias.0.Host.freeMem17881832179450.39450520995403915","round":null,"logDebug":false}
 285057   39891 iobroker    7  0.6 49568 554320 Sl   Mon Aug 31 15:33:37 2026 node            /usr/bin/node --max-old-space-size=1700 /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {"id":"Messwerte.0.HardwareDaten.Master.Speicher.mem_free","path":"/mnt/usbplatte/data/history/","start":1788161558739,"end":1788183158739,"count":300,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"min","limit":300,"addId":false,"sessionId":1056,"returnNewestEntries":false,"integralInterpolation":null,"removeBorderValues":false,"logId":"Messwerte.0.HardwareDaten.Master.Speicher.mem_free17881832179480.4657008882857676","round":null,"logDebug":false}
 285059   39891 iobroker    7  0.6 49584 750816 Sl   Mon Aug 31 15:33:37 2026 node            /usr/bin/node --max-old-space-size=1700 /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {"id":"alias.0.Host.memAvailable","path":"/mnt/usbplatte/data/history/","start":1788161558739,"end":1788183158739,"count":300,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"min","limit":300,"addId":false,"sessionId":1056,"returnNewestEntries":false,"integralInterpolation":null,"removeBorderValues":false,"logId":"alias.0.Host.memAvailable17881832179540.45382242273599815","round":null,"logDebug":false}
 285064   39891 iobroker    7  0.5 49104 617424 Sl   Mon Aug 31 15:33:37 2026 node            /usr/bin/node --max-old-space-size=1700 /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {"id":"Messwerte.0.HardwareDaten.Master.Speicher.memBuffered","path":"/mnt/usbplatte/data/history/","start":1788161558739,"end":1788183158739,"count":300,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"minmax","limit":300,"addId":false,"sessionId":1056,"returnNewestEntries":false,"integralInterpolation":null,"removeBorderValues":false,"logId":"Messwerte.0.HardwareDaten.Master.Speicher.memBuffered17881832179590.4791995853762201","round":null,"logDebug":false}
 285071   39891 iobroker    7  0.6 49680 685296 Sl   Mon Aug 31 15:33:37 2026 node            /usr/bin/node --max-old-space-size=1700 /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {"id":"system.host.ioBrokerpi5.freemem","path":"/mnt/usbplatte/data/history/","start":1788161558741,"end":1788183158741,"count":300,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"min","limit":300,"addId":false,"sessionId":1057,"returnNewestEntries":false,"integralInterpolation":null,"removeBorderValues":false,"logId":"alias.0.Host.freeMem17881832179680.021342402309211916","round":null,"logDebug":false}
 285077   39891 iobroker    7  0.6 49600 750816 Sl   Mon Aug 31 15:33:37 2026 node            /usr/bin/node --max-old-space-size=1700 /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {"id":"alias.0.Host.memAvailable","path":"/mnt/usbplatte/data/history/","start":1788161558741,"end":1788183158741,"count":300,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"min","limit":300,"addId":false,"sessionId":1057,"returnNewestEntries":false,"integralInterpolation":null,"removeBorderValues":false,"logId":"alias.0.Host.memAvailable17881832179820.20277489329472664","round":null,"logDebug":false}
 285093   39891 iobroker    7  0.5 49104 617424 Sl   Mon Aug 31 15:33:37 2026 node            /usr/bin/node --max-old-space-size=1700 /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {"id":"Messwerte.0.HardwareDaten.Master.Speicher.memBuffered","path":"/mnt/usbplatte/data/history/","start":1788161558741,"end":1788183158741,"count":300,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"minmax","limit":300,"addId":false,"sessionId":1057,"returnNewestEntries":false,"integralInterpolation":null,"removeBorderValues":false,"logId":"Messwerte.0.HardwareDaten.Master.Speicher.memBuffered17881832179950.6046703034490128","round":null,"logDebug":false}

davon gibt es noch mehr zeilen und wahrscheinlich sind das nicht alle, da das skript nur die ersten paar aufzeichnet.

jede zeile ist ein eigener task
den einzigen kandidaten hab ich hier gefunden
https://github.com/ioBroker/ioBroker.history/blob/6957d59c009494caf798bea9fb32fe57c8b17f53/src/lib/getHistory.ts#L142
da scheint wohl node solche operationen als eigenen task auszuführen.
Das ist die Stelle bei der der history adapter die tagesdatei zu einem Datenpunkt liest.

aber wie weiter oben schon mal erwähnt und zu überprüfen:
zeichnest du insbesondere bei den speicherrelevanten datenpunkten JEDE Änderung auf?
ich weiß nicht in welchem zeittakt der iobroker intern die datenpunkte aktualisiert. die gehen dann ja auch in die history und wenn da alle paar millisekunden bzw 100 millisekunden eine änderung gibt, dann werden entsprechend viele dateien geöffnet.
gut der history adapter sammelt ein wenig die daten in einem cache, aber wenn der voll ist, muss er schreiben.

[OliverIO]

@Homoran sagte:

Ich würde erst wieder etwas senden, wenn deine KI mehr Informationen braucht oder der iob gekillt wurde

sende insbesondere die snapshot, die größer wie 200k sind.
wenn ein oom kill dabei ist umso besser

[Homoran]

@OliverIO sagte:

da scheint wohl node solche operationen als eigenen task auszuführen.

Aaah, das passt!

Unter top tauchte ab und zu ei prozess "node" auf und verschwand sofort wieder

@OliverIO sagte:

die gehen dann ja auch in die history und wenn da alle paar millisekunden bzw 100 millisekunden

Nein, die sind nur höchstens alkec6 Sekunden.

Da müsste ich die system.host und system.adapter DP sicherheitshalber mal mit einer Blockzeit belegen!
Danke für den Tipp

@OliverIO sagte:

da war jetzt nur das um 1605 mit dem neuen skript von den snapshots.

Dann hab ich vielleicht die falschen hochgeladen.
Muss ich checken und tausche ggf. Aus

@OliverIO sagte:

sende insbesondere die snapshot, die größer wie 200k sind.
wenn ein oom kill dabei ist umso besser

Ok!
Damit kann ich was anfangen

[Homoran]

@OliverIO sagte:

da war jetzt nur das um 1605 mit dem neuen skript von den snapshots.

Geändert!

@OliverIO sagte:

die snapshot, die größer wie 200k sind.

sind sie alle bisher!
Sort by size:

Nicht chronologisch!
Was darf's sein?

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