Monatsrückblick Juli / August 2026 ist online!

[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

[OliverIO]

@Homoran

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#L1582

allerdings 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/erweitert

all das treibt das ram thema

warum das erst jetzt kommt

                        ---
                        | |
ram limit --------------------------------------------
            ---         | |
gethistory  | |         | |
            | |         ---
            ---         | |
andere      | |         | |
Anwendungen | |         | |
            | |         | |
            ---
           früher      heute

balken 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 habe

wahrscheinlich 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.

[Homoran]

@OliverIO Danke!
Jetzt reden wir über das gleiche! 😉
Fast!

@OliverIO sagte:

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/erweitert

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

@OliverIO sagte:

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.

@OliverIO sagte:

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

[OliverIO]

@Homoran

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-15W

ggfs gebraucht. im forum wird auch immer wieder von fujitsu berichtet.
ggfs gebraucht und dann eine neue ssd festplatte

ich 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.

[Michael Schmitt]

Wäre da nicht sowas ok ?? Gibts natürlich noch andere Konfigurationen.

Dell Optiplex 7070 Micro

Link

[OliverIO]

@Michael-Schmitt

wenn stromverbrauch nicht so eine rolle spielt.
Der Prozessor hat TDP 35W
ohne andere Komponenten zu berücksichtigen sind das im Mittel 15-25W

[Michael Schmitt]

also Kosten im Jahr unter 100€

[paul53]

@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.

[Homoran]

@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 mit lsblk erkannt, 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

[OliverIO]

@Michael-Schmitt sagte:

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€

https://geizhals.de/?cat=barepc&xf=17626_16~2508_Intel~2511_DDR4+SO-DIMM-Slot~4249_Mini-PC~6786_18~7223_PCIe+3.0+x4

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=uk

und 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=uk

ich 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