Load average am Anschlag -> Neustart
-
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 mitiobroker.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 aktivengetHistory.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.0ist 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.log1788190003254-snapshot_20260831_162341.log1788190003258-snapshot_20260831_162442.log1788190003266-snapshot_20260831_163935.log
Das große
memory.logenthä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.jsZombies 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.0Beispiele 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
mitwait()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 vonMemAvailableum 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=1700Ein 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.freememsystem.host.ioBrokerpi5.inputCountsystem.host.ioBrokerpi5.outputCountsystem.host.ioBrokerpi5.loadsystem.adapter.javascript.1.inputCountsystem.adapter.javascript.1.outputCountMesswerte.0.HardwareDaten.Master.CPU_Last.CPU_TempMesswerte.0.Solaranlage.Momentanwerte.Solarestimate2Messwerte.0.Solaranlage.Momentanwerte.Leistung_AC_aktuellMesswerte.0.Solaranlage.Momentanwerte.EigenverbrauchMesswerte.0.Stromzaehler.Momentanwerte.akt_VerbrauchMesswerte.0.Stromzaehler.Momentanwerte.akt_EinspeisungMesswerte.0.Batterie.LadungMesswerte.0.Batterie.Entladungalias.0.Stromzaehler.Bezug_aktuellmodbus.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 diesessionId-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
PageTablesundKernelStack, - 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.0die 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:- ein geöffnetes VIS-/VIS-2-Dashboard mit vielen oder zyklisch neu gerenderten
Diagrammen, - ein Flot-/ECharts-/Chart-Widget mit zu kurzem Refresh-Intervall,
- ein JavaScript unter
javascript.1, das vielegetHistory-Aufrufe startet,
ohne deren Abschluss abzuwarten, - 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.0aufgrund 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.0erklä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.0kontrolliert 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:- Alle Browser mit ioBroker-Visualisierungen schließen.
- Falls die Peaks aufhören, Browser/Views einzeln wieder öffnen.
- Falls sie weiterlaufen, verdächtige JavaScript-Instanz beziehungsweise
einzelne Scripts deaktivieren. - Besonders nach Scripts suchen, die
sendTo('history.0', 'getHistory', ...),
getHistory(...)oder periodische Chart-Aktualisierungen verwenden. - 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.historyfeststellen. - 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 --watchund gezielt:
grep -RniE "getHistory|sendTo.*history\.0|history\.0.*getHistory" \ /opt/iobroker/iobroker-data/files \ /opt/iobroker/node_modules 2>/dev/nullBei 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 aktivengetHistory.js-Prozessen.
Diese werden alle vonio.history.0erzeugt 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.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:system.host.ioBrokerpi5.freemem
system.host.ioBrokerpi5.inputCountsystem.adapter.javascript.1.inputCount
system.adapter.javascript.1.outputCountSind erst nach dem Auftreten der Probleme hinzugekommen!
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
kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
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:system.host.ioBrokerpi5.freemem
system.host.ioBrokerpi5.inputCountsystem.adapter.javascript.1.inputCount
system.adapter.javascript.1.outputCountSind erst nach dem Auftreten der Probleme hinzugekommen!
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
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 -
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 clientum 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!
du nutzt vis1
nur PC browser
Isch 'abe kein pezeh!
Nur Täblettjeder einzelne tab zählt auch als separater client
Ok!
Siehe obenDANKE!
kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
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!
du nutzt vis1
nur PC browser
Isch 'abe kein pezeh!
Nur Täblettjeder einzelne tab zählt auch als separater client
Ok!
Siehe obenDANKE!
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
Nur Täblett
was den apfel ??
zigbee hab ich, zwave auch, nuc's genauso und HA auch
-
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
Nur Täblett
was den apfel ??
wobei iframes erst dann wenn du es auf die sichtbare Seite umswitcht
Also nein!
Die belasten getHistory nicht.manche Browser
Gut dann wechsel ich nach dem nächsten Crash den Browser
was den apfel ??
Nöö robot
kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
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!
du nutzt vis1
nur PC browser
Isch 'abe kein pezeh!
Nur Täblettjeder einzelne tab zählt auch als separater client
Ok!
Siehe obenDANKE!
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 -
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. -
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 wechselstzigbee hab ich, zwave auch, nuc's genauso und HA auch
-
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 -
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 ThreadsFü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.
-
Mal quick&dirty!
Aktuell!
Absturz
Daten
snapshot_20260831_221940.log snapshot_20260831_221750.log
snapshot_20260831_221732.log
09011417memory.zipMemory.log musste ich zippen, ging so st nicht hier rein.
Fehlt noch was?
Wenn ich wieder etwas mehr Zeit hab
Kann ich experimentieren
kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
Mal quick&dirty!
Aktuell!
Absturz
Daten
snapshot_20260831_221940.log snapshot_20260831_221750.log
snapshot_20260831_221732.log
09011417memory.zipMemory.log musste ich zippen, ging so st nicht hier rein.
Fehlt noch was?
Wenn ich wieder etwas mehr Zeit hab
Kann ich experimentieren
Ich habe mir mal den history adapter angeschaut und den verursacher der threads gefunden
https://github.com/ioBroker/ioBroker.history/blob/6957d59c009494caf798bea9fb32fe57c8b17f53/src/main.ts#L1582allerdings ist dieser code bereits seit 10 jahren enthalten, also nix neues was evtl durch eine änderung in history v5 eingebracht wurde.
du kannst ja dennoch mal einen issue aufmachen, evtl sieht der maintainer da mehr. bspw einen prozesspool eröffnen, so das history nicht unlimitiert neue forks aufmacht, ggfs konfigurierbar. ergebnis wäre dann aber, das anfragen dann länger dauern, weil die abarbeitung dann auch verzögert wird, aber das ram limitierter genutzt wird.ich habe hier auch mal noch recherchiert. jeder fork aus gethistory erzeugt einen neuen prozess mit node. node hat wohl intern 7 threads, die irgendwas machen. aber das ist systeminterna von node und der v8 engine
aber es dreht sich immer um das gleiche thema: zu wenig RAM für die Anforderung.
du hast ja wahrscheinlich an deinem system schon änderungen vorgenommen:
node aktualisiert
iobroker aktualisiert
adapter aktualisiert
weitere datenpunkte in die Historisierung dazugenommen
ggfs weitere skripte dazugenommen/erweitertall das treibt das ram thema
warum das erst jetzt kommt
--- | | ram limit -------------------------------------------- --- | | gethistory | | | | | | --- --- | | andere | | | | Anwendungen | | | | | | | | --- früher heutebalken nicht proportional sehen.
meine bisherige empfehlung mit einer datenbank weiß ich auch nicht mehr ob das helfen könnte, da ja history wahrscheinlich immer noch die ganzen prozesse öffnet. ob die jetzt auf dateien oder auf ein datenbank request laufen dürfte egal sein. datenbank anfragen könnten ggfs etwas schneller beantwortet werden, so das nicht mehr ganz so viele prozesse so lang leben, wie ein dateizugriff notwendig machen, der länger dauert.
aber bei weiteren Erweiterungen verzögertes das erreichen des Limits auch nur temporär. ggfs macht der sql adapter da auch etwas anderes ohne forks, das habe ich mir jetzt nicht angeschaut. ausser du sagst du würdest das in auga fassen, was ich aber momentan nicht so das gefühl habewahrscheinlich ist ein prozess/workerpool im history da hilfreichste erweiterung.
oder mehr RAM :)
Die neuen logs habe ich der KI jetzt nicht mehr zugeführt, da sie ja das gleiche bild wie in den letzten schon.
-
Ich habe mir mal den history adapter angeschaut und den verursacher der threads gefunden
https://github.com/ioBroker/ioBroker.history/blob/6957d59c009494caf798bea9fb32fe57c8b17f53/src/main.ts#L1582allerdings ist dieser code bereits seit 10 jahren enthalten, also nix neues was evtl durch eine änderung in history v5 eingebracht wurde.
du kannst ja dennoch mal einen issue aufmachen, evtl sieht der maintainer da mehr. bspw einen prozesspool eröffnen, so das history nicht unlimitiert neue forks aufmacht, ggfs konfigurierbar. ergebnis wäre dann aber, das anfragen dann länger dauern, weil die abarbeitung dann auch verzögert wird, aber das ram limitierter genutzt wird.ich habe hier auch mal noch recherchiert. jeder fork aus gethistory erzeugt einen neuen prozess mit node. node hat wohl intern 7 threads, die irgendwas machen. aber das ist systeminterna von node und der v8 engine
aber es dreht sich immer um das gleiche thema: zu wenig RAM für die Anforderung.
du hast ja wahrscheinlich an deinem system schon änderungen vorgenommen:
node aktualisiert
iobroker aktualisiert
adapter aktualisiert
weitere datenpunkte in die Historisierung dazugenommen
ggfs weitere skripte dazugenommen/erweitertall das treibt das ram thema
warum das erst jetzt kommt
--- | | ram limit -------------------------------------------- --- | | gethistory | | | | | | --- --- | | andere | | | | Anwendungen | | | | | | | | --- früher heutebalken nicht proportional sehen.
meine bisherige empfehlung mit einer datenbank weiß ich auch nicht mehr ob das helfen könnte, da ja history wahrscheinlich immer noch die ganzen prozesse öffnet. ob die jetzt auf dateien oder auf ein datenbank request laufen dürfte egal sein. datenbank anfragen könnten ggfs etwas schneller beantwortet werden, so das nicht mehr ganz so viele prozesse so lang leben, wie ein dateizugriff notwendig machen, der länger dauert.
aber bei weiteren Erweiterungen verzögertes das erreichen des Limits auch nur temporär. ggfs macht der sql adapter da auch etwas anderes ohne forks, das habe ich mir jetzt nicht angeschaut. ausser du sagst du würdest das in auga fassen, was ich aber momentan nicht so das gefühl habewahrscheinlich ist ein prozess/workerpool im history da hilfreichste erweiterung.
oder mehr RAM :)
Die neuen logs habe ich der KI jetzt nicht mehr zugeführt, da sie ja das gleiche bild wie in den letzten schon.
@OliverIO Danke!
Jetzt reden wir über das gleiche! 😉
Fast!du hast ja wahrscheinlich an deinem system schon änderungen vorgenommen:
node aktualisiert
iobroker aktualisiert
adapter aktualisiert
weitere datenpunkte in die Historisierung dazugenommen
ggfs weitere skripte dazugenommen/erweitertJein!
Erstens hätte ich erwartet, dass sich dann ein solches oder ähnliches Problem schleichend, und nicht so mit voller Wucht bemerkbar macht.Außerdem habe ich in den letzten Tagen die beiden letzten Punkte gewaltig zurückgebaut, so dass ich daher
Homoran sagte:
bestimmt ein Jahr zurückliege
Blieben also nur die Punkte 1-3
node hat wohl intern 7 threads,
Ist jetzt mein Favorit
Wobei ich da vollkommen daneben liegen kann, da ich davon überhaupt nichts verstehe
Dann werde ich mir eine Strategie ausdenken müssen, wie ich mit den alten Daten irgendwie zurechtkommen kann
Demnach nutzt auch ein wechsel von flot zu eCharts auch nichts.
zu wenig RAM für die Anforderung.
Der 16gbit pi5 war mir zu teuer, hatte ihn schon im Warenkorb und dann gegen den 8er getauscht
kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
@OliverIO Danke!
Jetzt reden wir über das gleiche! 😉
Fast!du hast ja wahrscheinlich an deinem system schon änderungen vorgenommen:
node aktualisiert
iobroker aktualisiert
adapter aktualisiert
weitere datenpunkte in die Historisierung dazugenommen
ggfs weitere skripte dazugenommen/erweitertJein!
Erstens hätte ich erwartet, dass sich dann ein solches oder ähnliches Problem schleichend, und nicht so mit voller Wucht bemerkbar macht.Außerdem habe ich in den letzten Tagen die beiden letzten Punkte gewaltig zurückgebaut, so dass ich daher
Homoran sagte:
bestimmt ein Jahr zurückliege
Blieben also nur die Punkte 1-3
node hat wohl intern 7 threads,
Ist jetzt mein Favorit
Wobei ich da vollkommen daneben liegen kann, da ich davon überhaupt nichts verstehe
Dann werde ich mir eine Strategie ausdenken müssen, wie ich mit den alten Daten irgendwie zurechtkommen kann
Demnach nutzt auch ein wechsel von flot zu eCharts auch nichts.
zu wenig RAM für die Anforderung.
Der 16gbit pi5 war mir zu teuer, hatte ihn schon im Warenkorb und dann gegen den 8er getauscht
ja die preise sind um midnestens 50% gestiegen.
ich habe mir letztes jahr einen asus nuc 11, celeron mit ssd und 64GB für 300€ geholt. Jetzt für nicht unter 450 (ohne die 64GB).
lustigerweise konnte (kann?) man die NUCs (früher Intel, heute ASUS) mit bis zu doppelt soviel RAM bestücken, wie angegeben. verbraucht auch nur 10-15Wggfs gebraucht. im forum wird auch immer wieder von fujitsu berichtet.
ggfs gebraucht und dann eine neue ssd festplatteich finde die raspberrys in der größenordnung auch nicht mehr kostengünstig,
die busgeschwindigkeit lässt zu wünschen übrig, da gibt es in vergleichbarer preisklasse bessere prozessoren und bessere komponenten.wenn man denkt das die ersten raspis1 35€ noch gekostet haben.
Meine Adapter und Widgets
TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
Links im Profil -
Wäre da nicht sowas ok ?? Gibts natürlich noch andere Konfigurationen.
Dell Optiplex 7070 Micro
wenn stromverbrauch nicht so eine rolle spielt.
Der Prozessor hat TDP 35W
ohne andere Komponenten zu berücksichtigen sind das im Mittel 15-25WMeine Adapter und Widgets
TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
Links im Profil -
also Kosten im Jahr unter 100€
-
wenn stromverbrauch nicht so eine rolle spielt.
Der Prozessor hat TDP 35W
ohne andere Komponenten zu berücksichtigen sind das im Mittel 15-25W@OliverIO [sagte]:
wenn stromverbrauch nicht so eine rolle spielt.Leistungsaufnahme ca. 7 W und lüfterlos. Otto hat offenbar viele Asus PN42 auf Lager oder einen langfristigen Liefervertrag, denn alle anderen Anbieter sind erheblich teurer.
Ich habe eine DECT-Steckdose davor, um ihn nach dem Runterfahren per Fritz!Box starten zu können.
-
ja die preise sind um midnestens 50% gestiegen.
ich habe mir letztes jahr einen asus nuc 11, celeron mit ssd und 64GB für 300€ geholt. Jetzt für nicht unter 450 (ohne die 64GB).
lustigerweise konnte (kann?) man die NUCs (früher Intel, heute ASUS) mit bis zu doppelt soviel RAM bestücken, wie angegeben. verbraucht auch nur 10-15Wggfs gebraucht. im forum wird auch immer wieder von fujitsu berichtet.
ggfs gebraucht und dann eine neue ssd festplatteich finde die raspberrys in der größenordnung auch nicht mehr kostengünstig,
die busgeschwindigkeit lässt zu wünschen übrig, da gibt es in vergleichbarer preisklasse bessere prozessoren und bessere komponenten.wenn man denkt das die ersten raspis1 35€ noch gekostet haben.
@OliverIO ich habe noch einen alten, gerade ausrangierten NUC6i3 mit 16GB und einen nagelneuen, noch nie benutzten NUC11i3performance ich glaube damals hab ich sogar 32GB Speicher eingebaut. Da hatte ich nicht gelesen, dass der mindestens 12W braucht
Für das Geld bekommt man heute nicht einmal mehr 16GB RAM
Notfalls müssen die dran glauben.
Hab gerade den anderen pi5 mit der neuen USB NVMe ans laufen bekommen, ganz ohne SD.
Die wird zwar mitlsblkerkannt, muss aber wohl noch genauso gemountet werden wie vorher andersrum die SSD.Das wird das nächste Projekt, wenn es jetzt mit dem Urlaub nichts wird
-
also Kosten im Jahr unter 100€
also Kosten im Jahr unter 100€
klar das alleine ist ok
aber mit smarthome läppert sich das mit den ganzen anderen geräten
mein nuc mit celeron hat tdp15
ziel war aber auch da docker mit diversen containern laufen zu lassen (daher die 64gb) da reicht die Leistung gut aus.ein sprung vom raspi auf einen i3 ist schon ein großer.
ich denke er braucht nicht mehr leistung, sondern nur mehr ram.
neben celeron wäre auch ein n100 oder n150 mit einem tdp von 6 denkbar.sowas, das sind allerdings barebones. also mainboard mit prozessor und gehäuse. speicher und ssd muss man noch dazuholen. ab 160€
da kommen dann nochmal ab 256GB SSD M2 ab 50€ dazu
https://geizhals.de/?cat=hdssd&xf=7177_M.2+2280~7525_M.2+(PCIe)~8250_256GB+(240-256GB)&pagesize=30&sort=p&promode=false&hloc=at&hloc=de&hloc=pl&hloc=ukund 16gb ddr4 ram ab 100€
https://geizhals.de/?cat=ramddr3&xf=7500_DDR4~7501_SO-DIMM~7568_2~7569_8GB&pagesize=30&sort=p&promode=false&hloc=at&hloc=de&hloc=pl&hloc=ukich habe immer die etwas günstigeren anschlüsse oder RAM-Versionen gewählt. DDR5 will man aktuell nicht bezahlen wollen. Da gehts bei 16 GB ab 300€ los
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden444
Online33.0k
Benutzende83.7k
Themen1.3m
Beiträge