UNSOLVED Javascript - Blockly wird oft nicht gespeichert
-
@hg6806 said in Javascript - Blockly wird oft nicht gespeichert:
OK, danke allen für den super Support!
Quintessenz, also zumindest für meinen Fall, Systemüberlastung durch zuviele offene Datenpunkte und Laden der Werte.
Scheint mir mir ebenfalls gelegentlich die Ursache gewesen zu sein.
Folgendes löst das Problem bei mir das Kernproblem allerdings sofort und final:
\opt\iobroker\iobroker-data\iobroker.json
"noFileCache" = trueDie darunter liegende Hardware hat 64GB RAM, Intel I7 und SSD. System läuft auf Ubuntu Linux und langweilt sich die meiste Zeit.
Dennoch geschehen diese Speicherfehler unabhängig vom Browser und Plattform, von der aus aufgerufen wird.Für eine Weile konnte ich den Objektbaum minimieren und die Speicherung funktioniert wieder. Aber bei nun 300+ Skripten (allesamt recht minimalistisch, keine großen dabei) und einem großen KNX System, dass darüber angesteuert wird, half nur noch das Setzen des o.g. Parameters.
Was nun bleibt, ist dass das System nach und nach immer träger wird und das speichern langsam länger dauert. Aber es speichert erstmal wieder und setzt mir die Skripte nicht während der Bearbeitung wieder zurück.
-
@d-h-h Hm ... also jetzt müssten wir mal ganz tief schauen ...
noFileCache=true hat ausschliesslich eine Auswirkung auf Server-Seite und auch nur beim Zugriff auf Dateien aus dem iobroker Storage. Alles ist hier nicht relevant.
Bei die r ist auch die Frage ob es im Browser langsam wird oder auf Server seite. ALso du müsstest jetzt mal gaaanz viele Infos, beschreibungen was diu genau meinst , ggf ein Video und sowas bereistellen das wir helfen können.
Fakt ist für mich: Dieses Setting kann an sich für das hier beschriebene Theme KEINE Auswirkung haben
-
@apollon77 Hat es aber. Ohne die beschriebenen Einstellungen werden die verwendeten Browser - Chrome, Vivaldi und Edge - gleichermaßen langsamer. Ein Neustart des ioBroker Servers behebt jedoch alle Speicherprobleme - für eine gewisse Zeit. Egal welcher Laptop, egal welches OS, egal welcher Browser.
Der Server läuft derzeit wieder einige Tage - ich kann nach wie vor Speichern. Der Zeitraum, bis der Speichern Button erscheint, ist nach Änderungen ca. 1-2 Sekunden. Der Zeitraum vom drücken des Speicherbuttons bis zum erfolgreichen speichern ist wieder 1-2 Sekunden. Es geht also nicht "biltzschnell" aber man kann damit arbeiten.
Ohne die o.g. Änderung erscheint der Speichern Button erst gar nicht oder erst nach 1-2 MINUTEN. Teilweise werden Änderungen im Skript einfach wieder rückgängig gemacht und auf den Zustand zurückgesetzt, als das Skript aufgerufen wurde.
Den Speichern Button zu drücken hat manchmal Erfolg - nach 1-5 Minuten - manchmal passiert auch gar nichts. Manchmal setzt er auf Start zurück.Ich besitze eine eigene Software Entwicklungsfirma - bins ja gewohnt, dass mir Devs sagen "das kann gar nicht sein" und dann in voller Bewunderung selbst vor dem Problem stehen
Vielleicht ist es bei mir ja was anderes als bei den anderen Betroffenen hier - aber die anderen Beschreibungen hören sich für mich stark nach dem gleichen Problem an. Ein immer langsamer werdender Server, bis irgendwann der Cache voll ist.
Unter dem ioBroker liegt bei mir eine High Performance Maschine. Serverplatten im RAID 10. Linux Ubuntu Server 22.x. 64 GB RAM. i7 mit 3,8Ghz. Derzeit keine andren VMs am laufen.
Die Hardware langweilt sich - während das Speichern der Skripte scheinbar in Timeouts läuft.Das hat mit dem Browser nix zu tun. Fehlermeldungen im Browser sind lediglich, dass die Gegenseite nicht mehr antwortet.
Könnte es sein, dass der Server etwas aus dem Cache laden will und es dort nicht findet? Oder beim Schreibvorgang in den Cache schreibt und der nichts mehr aufnimmt?
Ich kann gern mal einen meiner Frond-End Devs dransetzen. -
@d-h-h bin jetzt nicht grad ein Guru oder Developer aber ein Poweruser und kann da nur sagen dass Dein Problem wohl an einem/mehreren "faulen" Skripten liegen könnte... Schleife, Cron,... Hatte Ähnliches Verhalten auch schon und nachdem ich meine Skripte kontrolliert und bereinigt hatte war dieses Verhalten verschwunden. Kann mich aber auch mal wieder täuschen.
VG -
@djmarc75 Und die Skripte sind nur faul, wenn der Cache nicht deaktiviert ist? Unwahrscheinlich.
-
@d-h-h sagte in Javascript - Blockly wird oft nicht gespeichert:
Und die Skripte sind nur faul, wenn der Cache nicht deaktiviert ist? Unwahrscheinlich.
war nur ein Tipp... halte mich dann gerne weiterhin raus und lass die Profis ran.
-
@d-h-h Strange. Also mit so einem System sollte sie Server Seite egal sein - Bzw wenn es langsamer wird dann eindeutig im CPU Verbrauch zu sehen sein. Wie ist es da?
Wie us RAM Verbrauch der Prozesse?Die meisten probs bisher bei sowas waren eher im Browser. Vor allem wenn Admin tabs über Tage offen sind und sich so mit Daten zufressen. Das hast du auch ausgeschlossen?
-
hi zusammen,
ich habe das problem auch extrem. ich kann kaum mit blockly arbeiten/speichern.
gibt es dazu neuigkeiten, wie man das beheben/umgehen kann? JS Controller ist 5.0.16 auf einem Raspi 4 mit 4 GB RAM
-
Sind die 4GB vielleicht etwas knapp bemessen? Wie viele Instanzen hast du laufen?
-
@saeft_2003 44 aktive momentan. plane auch ein baldiges hardwareupdate
--> https://forum.iobroker.net/topic/70483/zigbeedevices-nach-hardwaretausch-erneut-pairen/1ist sonst nur noch fhem und influxdb drauf
-
Puhh das ist echt viel. Ich hab 47 Instanzen bei 8 GB und es läuft sonst nichts mehr drauf.
Ich würde das Hardware Update so bald wie möglich machen und gleich proxmox mit eigenen VM/LXC
-
Laaangsam!!
Bei solchen issues geht es meist um den Rechner wo der Browser läuft. Schau mal bitte ob unter "Objekte"ggf viel aufgeplappt ist und klapp da mal alles zu. Dann besser? -
@apollon77 sorry dass ich so doof nachfrage, meinst du in einem anderen tab oder bei der selektion eines dp im auswahlmenü im blockly selbst
-
@tklein Nein ich meine generell .. und mehrere Tabs machen diese Art von problemen potentiell noch viel grösser. Im Locl storage (und den gibts nur EINMAL) wird sich gemerkt was aufgeklappt ist und mit mehreren tabs subscriben sich dann potentiell mehrere tabs für die gleichen daten und und und . Versuchs doch mal mit nur einem Tab ... und dort vor Javascript auf "Objekte gehen" und mal alles zuklappen.
Wenns dann besser ist kannst Du ja rumprobieren was es b ei dir auslöst das es wieder blöd wird.
Die vermutung ist das irgendwann der browser nur noch mit "State updates verarbeiten" beschäftigt ist und daher dann Javascript speichern stark verzögert wird
-
@apollon77 Da würde ich auch gern noch was zu beitragen
Und zwar habe ich hier einen Rechner, der nur für eine VIS zuständig ist und nichts anderes macht.Wenn ich an meinem Hauptrechner, anwelchem ich nur den Admin offen habe (Keine weiteren Instanzen / Tabs oder auch Internetseiten), jetzt das speichern eines blockly´s nicht funktioniert, lege ich damit auch die VIS auf dem anderen Rechner lahm. Dort geht in der Zeit des Speicherversuchs auch nichts mehr. Genauso wie das keine weiteren Skripte in dieser zeit ausgeführt werden. (Flurlicht, HUE-Beleuchtungen, State-Aufnahmen des Stromzählers usw)
Ebenso ist es, wenn ich einen neuen Datenpunkt auswählen möchte und die einzelnen States erstmal geladen werden müssen. Auch dann ist die VIS und alle Skripte lahmgelegt, Im Objekte-Baum habe ich selten "mehr" offen....
Ich hoffe ich habe verständlich geschrieben
-
@djnetwork Ok das würde klingen als ob entweder der js-controller aus dem Tritt kommt (nur so wären die Effekte auf andere Visus zu erklären) oder der Admin Adapter aus dem tritt kommt 8als kommunikationsweg ... wobei Vis ja über web geht, aber ggf nicht der Fall) ... keine Skripte ausgeführt wäre potentiell JavaScript Adaopter ... oder irgendwas komplett generelles wie RAM, Swapping und sonst was ...
Solche fälle müsste man sich also mal mit laufendem "top" auf dem Host ansehen was genau passiert und ggf debug log bei Javascript oder so -
@apollon77 danke für die erklärung. dann werde ich die anzahl der tabs minimieren.
-
@tklein Auf jeden Fall einen Versucht wert. Am Ende müsste man soetwas aber sehen das beim js-controller oder in Admin oder in web die CPU-Last auf dem Server hoch geht. Am End ehat jeder Tab eine Websocket verbindung und darüber fliessen daten ... ggf die gleichen u.a. ... irgendwann ist das halt sehr viel
-
@apollon77 hat leider nix gebracht. Besonders beim Zugriff auf DP die bei mir unter 0_userdata bzw alias liegen kommt mir es häufiger vor.
Update: Jetzt bei 780 MB, ohne dass ich etwas editiere
-
@tklein ok was genau soll der letzte Post bedeuten? Ich hab’s nicht verstanden.
