Fehler: "File tab.html not found"
MichaelSchaaf999 opened this issue · 19 comments
Describe the bug
Beim Aufruf von http://192.168.178.201:8081/#tab-echarts wirft das System einen Fehler.
eCharts lässt sich nicht mehr aufrufen.
Fehler: "File tab.html not found".
Instanz echarts.0 ist aber grün und läuft.
To Reproduce
...
Expected behavior
Aufruf von eCharts sollte möglich sein.
Screenshots & Logfiles
Versions:
-
Adapter version: <1.4.16> -
JS-Controller version: <5.0.5> -
Node version: <18.16.0> -
Operating system: <Debian 4.19.269-1> in einer Proxmox-VM
Additional context
Add any other context about the problem here.
"iob upload echarts" funktioniert?
Ja, "iob upload echarts" funktioniert.
Danach wird bei "http://192.168.178.201:8081/#tab-echarts" wieder wie erwartet angezeigt.
eCharts lassen sich auch editieren.
Eine Auffälligkeit nach einem Neustart des iob:
Debian GNU/Linux 10 jobroker tty1
lobroker login: michael
Password:
Last login: Sun Jun 25 18:27:50 CEST 2023 on tty1
inux jobroker 4.19.0-23-amd64 #1 SMP Debian 4.19.269-1 (2022-12-20) ×86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
michael@obroker:~$ [ 536.606206] Out of memory: Kill process 426 (obroker.js-con) score 310 or sacrifice child
536.606257] Killed process 1655 (node) total-vm: 2412532kB, anon-rss: 1728560kB, file-rss: 4kB, shmem-rss:okB
Auch der Befehl "iob upload echarts" zeigte am Ende diese Auffälligkeit:
upload (2] charts /opt/iobroker/node_modules/iobroker.echarts/www/static/js/main.eboafecd.jsstatic/js/main.eboafecd.jsapplici
tion/javascript
upload [1] charts /opt/jobroker/node_modules/iobroker.echarts/www/static/js/main.eboafecd.js.LICENSE.txtstatic/js/main.eboafec
djs.LICENSE.txt text/plain
upload [0] echarts/opt/jobroker/node_modules/iobroker.echarts/www/static/js/main.eboafecd.js.mapstatic/js/main.eboafecd.js.mar
application/ ison
722.609352] Out of memory: Kill process 1720 (node) score 332 or sacrifice child
722.610643] Killed process 1720 (node) total-vm:3029468kB, anon-rss:2317072kB, file-rss:0kB, shmem-rss:0kB
/usr/bin/iob: Zeile 10: 1719 Getötet sudo -H -u jobroker node /opt/lobroker/node_modules/jobroker.js-controller/
lobroker.js"$8"
michael@iobroker:~$
"Getötet" klingt nicht gut.
"Out of Memory" ist insofern erstmal unverständlich, weil der Speicher vom iob doch nicht anzeigt, dass der erschöpft ist:
Is schon klar: Die Fehlermeldung kommt ja nicht von ungefähr.
Aber: Was kann oder muss ich da tun?
AM besten Forum Thema, "free -m" sagt was?
@Apollon77
"free -m" bringt 171 Fundstellen im Forum. Das ist nicht meine Welt, sorry.
Hab mich aber ETWAS vorgetastet, indem ich "io diag" gegeben habe, mit dem Zusatz "| less" und finde sodann in einer Flut von Meldungen dies, Auszug:
2023-06-26 09:00:56.164 ESC[31merrorESC[39m: javascript.o (1736) script.js.Automatisierungen.Zeit. -nach_Tageszeit. GutenMorge
n Script_ UBERWACHEN: GutenMorgen-Script AKTUALISIERT - warum?
2023-06-26 09:12:28.799 - ESC[31merrorESCI39m: javascript.o (1736) script.js.Automatisierungen.Maschinen_u_Geräte.HmIP_überwact
ung_CCU: CCU Servicemeldungen wurden aktualisiert
2023-06-26 09:20:00.006 ESC[31merrorESC[39m: javascript.o (1736) script.js.Automatisierungen.GUI_Menü_&_Tahoma. Tahoma_Katzenk
lappe_Überprüfung_Jalousie.-4: Katzenklappe ist frei bei Jalousie 4 - Meldung 1
2023-06-26 09:30:08.111 ESC[81merrorESC[89m: host.jobroker instance system.adapter.ical.o could not be started: spawn ENOMEM
2023-06-26 09:45:00.015 ESC[81merrorESC[89m: host.jobroker instance system.adapter.solaredge.o could not be started: spawn EN
ОМЕМ
2028-06-26 09:48:56.524 ESC [81merrorESC [89m: host. jobroker Cannot read disk size: spawn ENOMEM
2023-06-26 09:50:00.015 ESC [81merrorESC 89m: host.jobroker instance system.adapter.solaredge.o could not be started: spawn EN
ОМЕМ
2028-06-26 09:50:04.027 ESC [81merrorESC [89m: host.jobroker instance system.adapter.zoe2.0 could not be started: spawn ENOMEM
2023-06-26 09:55:00.016 ESC31merrorESC(39m: host.iobroker instance system.adapter.solaredge.o could not be started: spawn EN
"EM
28-06-26 09:58:56.589 ESC [81merrorESC (89m: host. jobroker Cannot read disk size: spawn ENOMEM
ESC [31merrorESC [39m: host.iobroker instance system.adapter. solaredse.o could not be started: spawn 23-06-26 10:00:00.018
ШМЕМ
2023-06-26 10:00:04.029 ESCI81merrorESC[89m: host. lobroker instance system.adapter.zoe2.0 could not be started: spawn ENOMEM
2023-06-26 10:00:08.040 ESC31merrorESC (39m: host.iobroker instance system.adapter.ical.o could not be started: spawn ENOMEM
2023-06-26 10:05:00.012 ESC [31merrorESC [39m: host.iobroker instance system.adapter.solaredge.o could not be started: spawn En
OMEM
2023-06-26 10:08:56.597 ESC [81merrorESC [39m: host. lobroker Cannot read disk size: spawn ENOMEM
2023-06-26 10:10:00.017 ESC [31merrorESC [39m: host.iobroker instance system.adapter.solaredge.o could not be started: spawn En
ОМЕМ
2023-06-26 10:10:04.026 ESC [31merrorESC [39m: host. lobroker instance system.adapter.zoe2.0 could not be started: spawn ENOMEM
2023-06-26 10:15:00.015 ESC [31merrorESC [39m: host.iobroker instance system.adapter.solaredge.o could not be started: spawn En
ОМЕМ
(teilweise kryptischer Inhalt: Liegt an der Texterkennung des Bildschirm-Screenshots)
Daraus lese ich mit laienhaftem Verstand, dass das System sehr wohl ein Speicherproblem hat.
Stelle auch gerade mit Begeisterung fest, dass solche "ENOMEM"-Meldungen sich ja auch in der Logdatei befinden. Mit den Logs kann ich halbwegs/besser umgehen als mit io-diag auf der Konsolen-Ebene.
Nun: Zweifelsfrei ist ENOMEM dann wohl der Hinweis auf nicht genügend RAM.
Obwohl die VM ja eiiiigentlich genügend Speicher haben sollte:
Aber wenn Prozesse scheitern wegen ENOMEM, dann ist ja auch noch RAM frei, das erklärt wohl die freien ca. 17% RAM.
Langer Rede kurzer Sinn:
-
Das iob-System ist gewachsen, jetzt "zu groß" für die 5,98 GiB RAM?
-
Mehr RAM zuweisen?
-
Kann man das iob-System eigentlich optimieren, also bspw Views auf mehrere Projekte aufteilen oder ähnliche Maßnahmen?
Bitte "free -m " auf der kommandzeile ausführen und die AUsgabe posten. War nicht als suche gedacht
PS: aber ja auch die Adapter die nicht gestartet werden können mit ENOMEM sagen klar das da irgendwie dein RAM voll ist. je nachdiem wieviele Adapzter Du nutzt kann das mehr btrauchen.
m,ach mal zusätzlich noich die Ausgabe von "top" dazu und nach dem Starten einmal Shift-S drücken dann sollten die prozesse nach RAM verbrauch sortiert sein.
free -m:
bei "free -m top" kommt keine andere Ausgabe
nur "top"
nur top, okay, mit shift-S:
Wobei ich dazu sagen muss, dass ich die RAM-Zuweisung für den iob gerade hochgesetzt habe.
lso wenn ich die "RES" spalte addiere kommt ich für iobroker prozesse maximal auf 2GB mit aufrunden ... was läuft da noch? Oder es passiert erst nach einiger Zeit weil sich irgendwas mit RAM zufrisst. Musst Du mal beobachten
Hier die Kurve des RAM:
Langsam aber stetig scheint das zu steigen. 3,79 GiB zur Zeit...
Danke für die Unterstützung!!
Am ehesten ist da @GermanBluefox der richtigere Ansprechpartner. Am Ende ist es wie du vermutest: Es werden zu Beginne ALLE States geladen die in den views genutzt werden auch wenn diese nicht angezeigt werden und werden danach aktuell gehalten, sodass das umschalten einer View eine reine Client-Seitig Aktion ist die nichts vom Server braucht.
Je nachdem wie groß das Projekt ist kann dies durchaus eine Weile dauern Mit js-controller 5 sollte es vllt schneller gehen an dieser einen Stelle. Den Rest - vor allem mit Tablets rauszfinden ist meist mühselig weil es keinen Zugriff auf die JavaScript-Konsole gibt wie auf dem PC.
Ingo
Hallo Ingo, ++++konzeptionelle Fragen zur Projektgestaltung und Performance+++++
ich weiß, dieser Thread gehört hier eigentlich nicht in dieses gecloste Issue, aber sollte ich für diese Frage einen separaten Github-Eintrag machen? Wenn ja: Unter VIS? VIS wird ja nun nicht mehr weiterentwickelt, hab ich gelesen. Und diese Thematik ist ja auch kein Bug/Issue, sondern höchstens eine Frage der performanten Projektgestaltung, wenn Projekte "zu groß" werden.
Wo legt man so ein Thema also hin? Ins Forum? Gibt es da so einen Bereich für konzeptionelles/architektonisches Gestalten von Projekten unter iOBroker / VIS?
Ich habe übrigens eine quick and dirty Lösung angedacht und auch schon testweise ausprobiert: Splitten eines Projektes auf zwei Projekte, also sinnvoll zusammengehörende Views von beispielsweise 35 Temperaturanzeige-Views (aus gesamt ca. 95 Views) in ein eigenes Temperaturanzeige-Projekt packen.
Dann hat man in den nur noch 60 verbleibenden Views im Hauptprojekt einen Button, der das Temperaturanzeige-Projekt mit seinen 35 Views lädt und dort dann einen Button, der das Hauptprojekt wieder lädt.
Das ist keine sehr schöne Lösung, es werden dann ja bei Bedarf auch zwei Projekte hin- und hergeladen, aber es ist eine pragmatische Lösung, die vermutlich sofort drastisch den Traffic und Load und den Speicherbedarf für ein Anzeige-Tablet so reduziert, dass es wieder deutlich schneller/smoother abläuft.
Wenn es für Riesenprojekte keine andere architektonische Lösung im iOBroker gibt, dann müsste ich das in diesem speziellen Fall so machen.
VIS2 ist da auch nicht besser geeignet, oder? Warum auch - ist ja ein Problem der Site hier und nicht des Visualisierungs-Adapters.
VIS2 ist eh noch kein Thema für jemanden wie mich, also für Otto-Normal, oder?
LG
Michael
"Vis wird nicht weiterentwickelt"?? Vis 1.x wird nicht mehr weiterentwickelt, aber im Vis Repo ist alles auf vis 2 und das ist das woran gerade mit hochdruck gearbeitet wird. ALso ja - vis Fragen bitte ins Vis Github
Böser Fehler von mir. Ja: VIS1 wird nicht mehr weiterentwickelt, klar. Ohne ein VIS könnte ich meine Projekte ja auch alle einstampfen - das geht nicht. VIS2!
Kann man eigentlich schon testen oder muss man auf ein Release warten?
LG