[gelöst] Javascript-Adapter Speicherproblem memRSS
-
Ich habe ein böses Problem mit dem Javascript-Adapter.
Meine ursprüngliche Hauptinstallation (iMac mit 4GB RAM) hat sich auf Grund von Speicherproblemen (out of memory) im Javascript-Adapter so abgeschossen, so dass ich sie nicht wieder zum Laufen bekommen habe.
Bei meiner neuen Installation auf einer VM mit 8 GB RAM, habe ich nun wieder das gleiche Problem.
Im Unterschied zu alten Installation habe ich den Speicher für die Javascript-Adapter unter Objekte im Expertenmodus je Instanz auf 200 MB begrenzt und kann nun wenigstens weiterarbeiten (im Hintergrund startet dann immer mal wieder eine Javascript-Instanz neu).
Umgebung:
4 Javascript-Instanzen:
javasript.0 - getestete Skripts
javasript.1 - Skripts, die Daten aus externen Quellen holen
javasript.2 - Testumgebung (kein Skript aktiv)
javasript.3 - globale Skripts (wobei hierfür keine eigene Instanz benötigt würde)
npm: 2.15.1
node.js: 4.4.3
js-controller 0.8.7
javascript-Adapter 2.0.6
Ubuntu 16.04.
vm auf ESXi, 8 GB RAM
Ein Zusatzmodul installiert: dewpoint
Das Diagramm oben zeigt den Datenpunkt system.adapter.javascript.2.memRss.
In der Javascript.2 Instanz ist kein einziges Skript aktiv. Trotzdem ging dort und in den anderen drei Instanzen der Speicher im Datenpunkt memRSS von knapp 40-50 MB auf über 400 MB hoch.
Es waren nur wenige Schritte, wovon einer dann zum Speicherproblem geführt hat:
-
.0 Skript "Ereignisliste" wurde in "Ereignisliste_gross" unbenannt
-
.0 Skript es wurde ein neuer Skriptordner "Ereignisliste" angelegt (hier gab es Meldungen, s.u.)
-
.0 Skript in "Ereignisliste" wurde ein Skript "Luftgüte" angelegt (noch ohne Inhalt)
-
.0 Skript eine kurze Funktion deltazeit(), s.u. wurde aus "Ereignisliste_gross" (vorher gestoppt) raus kopiert und global neu als Skript (.3) eingefügt
hier fingen die Probleme wahrscheinlich an
-
das globale Skript deltazeit() wurde wieder gelöscht, da die Adapter nun immer neu starteten
-
die VM wurde neu gestartert
Alle beteiligten Skripte sind deaktiviert oder gelöscht. Trotzdem läuft das System nicht mehr sauber.
Das Mini-Skript deltazeit() als globale Funktion (benutzt eine andere globale Funktion dateEpocheNow()):
function deltazeit(datenpunkt) { var letzterVorgang = getState(datenpunkt).val; var delta = Math.floor((dateEpochNow() - letzterVorgang) / 1000); setState(datenpunkt,dateEpochNow()); return durationForm(delta); }[EDIT]
unter javascript.0.scriptEnabled.global.deltazeit(datenpunkt) gab es noch dem Löschen des globalen Skripts noch einen Eintrag, der da nciht hingehörte. Den habe ich manuell gelöscht und den Rechner neu gestartet. Leider sind danach die memRSS Probleme ncoh größer geworden:
0: 470, 1: 240, 2: 310, 3: 280 MB memRSS je Javascript Instanz.
[/EDIT]
Der Zustand nach dem Rückgängig machen des globalen Skripts und den deaktivieren aller beteiligten Skripte (auch die Ereignisliste, nun Ereignisliste_gross, die vorher ohne Beanstandung lief):
Die Javascript-Instanz ist nach dem Reboot (erst nach dem Reboot) auf 100 MB memRSS zurückgegangen (immer noch fast doppelt soviel, wie vorher).Dies gilt auch für Instanz .2 (keine aktiven Skripte) und .3 (nur globale Skripte, die dann ja nicht in der Instanz laufen).
Die Javascript Instanz .0 zeigt immer noch über 400 MB memRSS an, obwohl seit dem "Fehler" kein Skript aktiv ist.Was mir beim Javascript-Adapter generell auffällt. Beim Anlegen von Verzeichnissen oder Skripte kommen immer mal wieder Meldungen, wie (Duplicat, not find, …). Skripte oder Verzeichnisse können nicht gelöscht werden, usw. Skripte oder Verzeichnisse werden in "null" angelegt. Dies kann man dann nur in den Admin/Objekten "reparieren".
Was mir wirklich Sorge macht, ist dass man (ich) das Problem nicht reparieren kann (alle Skripte deaktivieren bringt nichts, Schritte rückgängig machen bringt nichts). Es hat mich bis jetzt richtig Zeit gekostet (Ausfall Hauptsystem) und verdirbt mir etwas die Laune
-
-
Was mir beim Javascript-Adapter generell auffällt. Beim Anlegen von Verzeichnissen oder Skripte kommen immer mal wieder Meldungen, wie (Duplicat, not find, …). Skripte oder Verzeichnisse können nicht gelöscht werden, usw. Skripte oder Verzeichnisse werden in "null" angelegt. Dies kann man dann nur in den Admin/Objekten "reparieren". `
Das Problem habe ich auch (Chrome auf Windows 10 und Chromium auf Ubuntu).
Das nervt wirklich tierisch und versaut einem die Laune am Skripten, wenn man bei jeder kleinen Änderung und beim probieren einen Workaround machen muss, weil er mal wieder nicht speichern will ("Duplicate" oder "null"). Manchmal geht es problemlos, oft geht es aber gar nicht.
Mein Workaround ist: Skriptinhalt kopieren, neues Skript anlegen, dort alles reinkopieren, speichern, das alte Skript löschen.
-
Nach einem weiteren Reboot (ohne sonstige Änderungen) nach der Nacht, ist der Speicherdruck in der Instanz .0 interessanterweise wieder normal:
Die Instanzen .1 bis .3 verbrauchen weiterhin je über 200 MB, obwohl nur in Instanz .1 ein einziges Skript aktiv ist.
Am Beispiel der Instanz .2:
Ich habe mich durch die ioBroker Dateien und die objects.json gewühlt. Die Stelle, an der die globalen Skripte vor den anderen Skripten kopiert werden, habe ich allerdings nicht gefunden. Passiert dies nur im Speicher? Dann müsste das Problem ja nach einem Reboot gelöst sein, was es nicht ist.
Das Skript deltazeit(datenpunkt), welches ich oben erwähnt hatte und mit dem aus meiner Sicht die Probleme anfingen, gab es in einem 2., noch aktiven Skript, auch noch. D.h. es wurde als globales Skript ein zweites Mal davor kopiert.
Das der Javascript-Editor oft muckt, s.o. ist ärgerlich, damit kann man aber noch gut leben (Prio 2, eher 3).
Das sich das ganze System weghängt, weil der Javascript-Adapter "spinnt". Ist für mich deswegen Prio 1, da ich als Normalanwender anscheinend keine Möglichkeit habe, das Problem "zu reparieren".
-
Was mir beim Javascript-Adapter generell auffällt. Beim Anlegen von Verzeichnissen oder Skripte kommen immer mal wieder Meldungen, wie (Duplicat, not find, …). Skripte oder Verzeichnisse können nicht gelöscht werden, usw. Skripte oder Verzeichnisse werden in "null" angelegt. Dies kann man dann nur in den Admin/Objekten "reparieren". `
Das Problem habe ich auch (Chrome auf Windows 10 und Chromium auf Ubuntu).
Das nervt wirklich tierisch und versaut einem die Laune am Skripten, wenn man bei jeder kleinen Änderung und beim probieren einen Workaround machen muss, weil er mal wieder nicht speichern will ("Duplicate" oder "null"). Manchmal geht es problemlos, oft geht es aber gar nicht.
Mein Workaround ist: Skriptinhalt kopieren, neues Skript anlegen, dort alles reinkopieren, speichern, das alte Skript löschen. `
Wie kann ich das reproduzieren? -
Javascript ist einer von wenigen Adaptern, welcher auf alle Variablen zuhört.
Vielleicht hast du mega States oder Mega Objekte in deinem System? JSON Tabellen?
Und auch wenn der Adapter nichts zu tun hat hört er trotzdem auf alle Änderungen und und nimmt Speicher dafür.
-
Javascript ist einer von wenigen Adaptern, welcher auf alle Variablen zuhört.
Vielleicht hast du mega States oder Mega Objekte in deinem System? JSON Tabellen?
Und auch wenn der Adapter nichts zu tun hat hört er trotzdem auf alle Änderungen und und nimmt Speicher dafür. `
Nein, habe ich nicht. Deswegen habe ich oben genau beschrieben, was ich gemacht habe, als es dazu gekommen ist.
Ich habe auch nur einen Teil der Skripte umgezogen, die vorher auf anderen System liefen.
Das Problem ist auch mehr, dass man es nicht reparieren kann. Wenn es einmal anfängt, warum auch immer, kann man es nicht mehr in Ordnung bringen.
Siehe:
Javascript Instanz .0 hat sich nach dem 2. Reboot nach der Nacht "beruhigt". Warum? Und warum nicht nach den ersten Reboot? Beim iMac konnte ich machen was ich will. Ich habe alle Scripts deaktiviert und es lief trotzdem nie wieder.
Die Instanzen .1 bis .3 ziehen alle 4-5 mal so viel Speicher, wie sonst.
In der Instanz .2 ist gar nichts aktiv und trotzdem wird der Speicher verbraucht.
In der Instanz .3 sind die globalen Skripte eingeschaltet. Die sind 1:1 identisch, wie es vor dem Problem war. Trotzdem der Speicherverbrauch.
In Instanz .1 nur das Script zum auslesen des WIFFI 2.0 (ein kurzes JSON über Web).
Warum ziehen die Instanzen .1, .2 und .3 den Speicher? Angefangen hat das erst, als ich die Kleinigkeiten, die ich oben beschrieben hatte, angegangen bin.
Ist es ggf. ein konzeptionelles Problem mit den globalen Skripten?
Wo werden die Skripte global mit den anderen Skripten zusammengebaut? Im Filesystem nicht oder?
Es kann doch nicht sein, dass das Rauskopieren einer Minifunktion das ganze System auf den Bauch liegt.
Auch das man es nicht reparieren kann, ist für mich ein Problem.
Ich habe jetzt alle restlichen noch laufenden Skripte deaktiviert und folgendes Verhalten gehabt:
Kurz nach dem Deaktivieren des letzten Skripts:
Nach ca. 10 Minuten:
Nach einem weiteren Reboot, exemplarisch für Instanz .1:
Instanz .1
Kein Skript aktiv.
Speicher beruhigt sich nicht.
Nach dem Reboot geht der Verbrauch auf > 600 MB hoch, dann zurück auf ca. 250 MB. Normal sollten 40-50 MB sein.
Das ist aus meiner Sicht kein Problem eines großen JSON oder vieler Variablen, sondern ein grundlegendes Problem
Ich verzweifle gerade etwas. Weiss nicht, was ich tun kann. Wenn ich zum dritten Mal ein System aufsetzen muss, wüsste ich wenigstens gerne, woran das liegt/lag und was man tun kann.
-
Bevor ich jetzt wieder Stunden Arbeit über Bord werfe und dann ein drittes Mal ins Messer laufe…
Hat noch jemand eine Idee?
Eine Idee, warum die Javascript-Instanzen den kompletten Speicher ziehen, ohne dass auch nur ein Skript aktiv ist?
Gibt es Vorschläge für Reparaturversuche, die nicht die bestehenden Daten zerstören?
-
Hier ist beschrieben wie du vorgehen kannst um herauszufinden wodurch so viel Speicher belegt wird.
-
Danke Dir. Harter Tobac
Wird jetzt schwierig, da ich jetzt das gleiche Problem, wie beim iMac habe. Der Speicher bei den vier Javascript-Instanzen schaukelt sich auf das verfügbare Maximum hoch (8GB) und dann wird der js-controller Prozess beendet. Alle anderen io.* Prozesse sind noch da. Ich bekomme es nicht mehr zum laufen.
Wie ist es dazu gekommen:
Ich hatte noch einmal die Skripte aktiviert und neu gestartet. Danach alles deaktiviert. Der Speicherverbrauch hatte sich verschlimmert bis zum Totalabsturz.
Für mich unverständlich, das der Javascript-Adapter für den Absturz des js-controllers sorgt, ohne das überhaupt ein Skript aktiv ist.
-
Danke Dir. Harter Tobac
Wird jetzt schwierig, da ich jetzt das gleiche Problem, wie beim iMac habe. Der Speicher bei den vier Javascript-Instanzen schaukelt sich auf das verfügbare Maximum hoch (8GB) und dann wird der js-controller Prozess beendet. Alle anderen io.* Prozesse sind noch da. Ich bekomme es nicht mehr zum laufen.
Wie ist es dazu gekommen:
Ich hatte noch einmal die Skripte aktiviert und neu gestartet. Danach alles deaktiviert. Der Speicherverbrauch hatte sich verschlimmert bis zum Totalabsturz.
Für mich unverständlich, das der Javascript-Adapter für den Absturz des js-controllers sorgt, ohne das überhaupt ein Skript aktiv ist. `
Du kannst doch eine Instanz aktiv lassen und die allein untersuchen. Dann wird Speicher nicht so schnell weg gefressen. -
Du kannst doch eine Instanz aktiv lassen und die allein untersuchen. Dann wird Speicher nicht so schnell weg gefressen. `
Dein ernst? Die Beschreibung sieht nicht so aus, als ob ich das hin bekomme. Oder meinst Du mit "Untersuchen" was anderes?
Wie geschrieben. Alle Skripts ausgeschaltet. Wenn nur die erste Instanz aktiv ist, zieht diese trotzdem 1,5 GB RAM.
Würde mir eventuell schon bei der Fehlersuche helfen, wenn ich die Infos habe, wie der Adapter arbeitet.
Wenn die Ursache nicht erkannt wird, werde ich immer wieder in den Fehler rein laufen können. Dazu habe ich wenig Lust.
Fragen
Wo werden die globalen Skripte mit den lokalen Skripten zusammenkopiert? Im Filesystem nicht oder?
Warum zieht eine Instanz 1,5 GB RAM, ohne dass überhaupt ein Skript eingeschaltet ist?
Da muss es doch einen Ansatz geben.
Was ich noch gemacht habe
-
iobroker-data gesichert
-
js-controller 0.8.9 manuell installiert
-
alle Adapter einzeln manuell neu installiert
-
iobroker-data zurückgespielt
-
Fehler ist noch da
-
alle Javascript Instanzen deaktiviert
Der Fehler ist irgendwo in iobroker-data.
Was ich jetzt noch machen werde:
-
Alle Skripte einzeln sichern (aus dem Editor mit Copy & Paste), dann löschen
-
Javascript Adapter wieder einschalten
-
a) wenn der Fehler dann weg ist:
– alle Skripte wieder nach und nach reinkopieren
- b) wenn der Fehler nicht weg ist (ohne Skripte)
-- keine Ahnung
Eigentlich sehe ich nicht viel Sinn darin, weil es genau mit den jetzt vorhanden Skripten gut lief. Wenn es dann funktioniert (a) ist das keinerlei Gewähr, dass das auch so bleibt, wenn nicht eine Kleinigkeit geändert wird.
Ehrlich gesagt bin ich extrem frustriert von dem Fehlerbild.
-
-
Dein ernst? Die Beschreibung sieht nicht so aus, als ob ich das hin bekomme. Oder meinst Du mit "Untersuchen" was anderes?
Wie geschrieben. Alle Skripts ausgeschaltet. Wenn nur die erste Instanz aktiv ist, zieht diese trotzdem 1,5 GB RAM. `
Du hast immer noch andere 6,5 GB zu nutzen
@ruhr70:Würde mir eventuell schon bei der Fehlersuche helfen, wenn ich die Infos habe, wie der Adapter arbeitet.
Wenn die Ursache nicht erkannt wird, werde ich immer wieder in den Fehler rein laufen können. Dazu habe ich wenig Lust.
Fragen
Wo werden die globalen Skripte mit den lokalen Skripten zusammenkopiert? Im Filesystem nicht oder? `
Die globale Skripte werden nie allein ausgeführt. Bevor ein nicht globales Skript gestartet wird, werden alle globale Skripte zu einem Text zusammengefasst und vor dem normalen Skript rein kopiert. Dann wird so eine Skript ausgeführt.Warum zieht eine Instanz 1,5 GB RAM, ohne dass überhaupt ein Skript eingeschaltet ist?
Da muss es doch einen Ansatz geben. `
JS Adapter hat im Bauch eine Kopie von allen Objekten und allen States. Dann auch bei jeder Änderung von einem Objekt oder Zustand werden die neue Daten abgespeichert (über alten, es gibt keine Historie). An dieser Stelle vermute ich Memory Problem.Du kannst versuchen das zu deaktivieren und dann RAM beobachten.
Schreib hier:
https://github.com/ioBroker/ioBroker.ja … ipt.js#L47
und hier
https://github.com/ioBroker/ioBroker.ja ... pt.js#L151
ein return und beobachte RAm.
Was ich noch gemacht habe
-
iobroker-data gesichert
-
js-controller 0.8.9 manuell installiert
-
alle Adapter einzeln manuell neu installiert
-
iobroker-data zurückgespielt
-
Fehler ist noch da
-
alle Javascript Instanzen deaktiviert
Der Fehler ist irgendwo in iobroker-data.
Was ich jetzt noch machen werde:
-
Alle Skripte einzeln sichern (aus dem Editor mit Copy & Paste), dann löschen
-
Javascript Adapter wieder einschalten
-
a) wenn der Fehler dann weg ist:
– alle Skripte wieder nach und nach reinkopieren
- b) wenn der Fehler nicht weg ist (ohne Skripte)
-- keine Ahnung
Eigentlich sehe ich nicht viel Sinn darin, weil es genau mit den jetzt vorhanden Skripten gut lief. Wenn es dann funktioniert (a) ist das keinerlei Gewähr, dass das auch so bleibt, wenn nicht eine Kleinigkeit geändert wird.
Ehrlich gesagt bin ich extrem frustriert von dem Fehlerbild. `
Kannst du mir über PN dein iobroker-data schicken? Ich kann auch versuchen mal RAM zu beobachten.
-
-
Was ich jetzt noch machen werde:
-
Alle Skripte einzeln sichern (aus dem Editor mit Copy & Paste), dann löschen
-
Javascript Adapter wieder einschalten
-
a) wenn der Fehler dann weg ist:
– alle Skripte wieder nach und nach reinkopieren
- b) wenn der Fehler nicht weg ist (ohne Skripte)
-- keine Ahnung
Eigentlich sehe ich nicht viel Sinn darin, weil es genau mit den jetzt vorhanden Skripten gut lief. Wenn es dann funktioniert (a) ist das keinerlei Gewähr, dass das auch so bleibt, wenn nicht eine Kleinigkeit geändert wird.
Kannst du mir über PN dein iobroker-data schicken? Ich kann auch versuchen mal RAM zu beobachten.Danke Bluefox. Da komme ich mit Sicherheit noch drauf zurück. :twisted:
Momentan teste ich noch wild und Du würdest mir riesig helfen, wenn Du ein Feedback hast sobald Dir was auffällt.
Ich habe jetzt erst einmal die Schritte oben durchgeführt:
-
diverse Reboots
-
bis auf die nackten Verzeichnisse common und global all Skripte im Admin gelöscht
-
in den Objekten unter scripte.js sind keine Skripte mehr vorhanden
-
reboot
-
die Javascriptinstanz .0 wieder gestartet
Für .0 ging der Speicher auf 1,5 GB hich und dann runter auf 400 MB,
Was bisher aufgefallen ist:
-
ohne Skripte besteht das Speicherproblem immer noch
-
in den Instanzen waren alle javascript.x.sriptEnable.SCRIPTNAME noch vorhanden
(diese Einträge musste ich alle manuell löschen)
-
das Skript reinstall.sh in /opt/iobroker kann nicht ausgeführt werden
(als root: ./reinstall.sh
bash: ./reinstall.sh: /bin/bash^M: Defekter Interpreter: Datei oder Verzeichnis nicht gefunden)
Ich suche weiter.
Wo kann den in iobroker-data noch was stehen, was "nicht normal" ist?
./files - habe ich durchgesehen, eher nein
./sqlite - auch nein
./history - auch nein
./node-red - nein. War in dieser Installation noch nie aktiv
bleiben:
states.json und
objects.json
Die sehen mittlerweile "sauber" aus. Ich forsche hier weiter.
Für einen Schubser, wo ich sonst gucken kann, wäre ich dankbar.
-
-
Ich habe in meinem letzten Antwort was mit Formatierung vertauscht.
Schaue bitte mein Antwort noch mal an:
-
Du hast immer noch andere 6,5 GB zu nutzen
`Der ESXi Host hat 32 GB. Zur Not schraube ich das auch noch hoch :lol:
Ich habe ja bei jeder Javascript-Instanz den Speicher auf 200 MB begrenzt und trotzdem geht der Speicher je Instanz auf bis zu 1,5 GB hoch. Greift das nicht oder verstehe ich die Speicherbegrenzung falsch?
JS Adapter hat im Bauch eine Kopie von allen Objekten und allen States. Dann auch bei jeder Änderung von einem Objekt oder Zustand werden die neue Daten abgespeichert (über alten, es gibt keine Historie). An dieser Stelle vermute ich Memory Problem. `
mmh… dann könnte doch auch ein Objekt/State von einem anderen Adapter das Problem verursachen, wenn sich dort viele Zustände schnell ändern würden? Ich kann ja mal nach und nach die anderen Adapter deaktivieren.
Das passt allerdings nicht zu dem Vorgang, ab wann das Problem aufgetreten ist (Änderungen bei den Skripten).
Du kannst versuchen das zu deaktivieren und dann RAM beobachten.
Schreib hier:
https://github.com/ioBroker/ioBroker.ja … ipt.js#L47
und hier
https://github.com/ioBroker/ioBroker.ja ... pt.js#L151
ein return und beobachte RAm. `
Erledigt. Stop/Start iobroker und Reboot Rechner.
Speicher geht trotzdem erst auf 1,5 GB in Instanz.0 und dann auf 400 MB.
objectChange: function (id, obj) { return; // DEBUG Zeile 47 if (this.regExEnum.test(id)) {stateChange: function (id, state) { return; // DEBUG Zeile 151 if (id.match(/^messagebox\./) || id.match(/^log\./)) return; -
> Speicher geht trotzdem erst auf 1,5 GB in Instanz.0 und dann auf 400 MB.
Beim start werden alle Objekte und States einmal gelesen (1,5GB).Dan wird vermutlich der Speicher, der für lesen benötigt war freigegeben (400MB). Dann sollte aber es konstant bleiben.
1.5GB… wie viel Objekte hast du?
Man kann "_id" in objekts.json zählen.
-
Nachtrag:
-
alle Adapter, bis auf admin und javascript.0 deaktiviert.
-
die beiden return in der javascript.js sind eingefügt
Der Speicherverbrauch geht in der einen aktiven Javascript-Instanz .0 trotzdem auf 1,5 GB hoch
-
-
> Speicher geht trotzdem erst auf 1,5 GB in Instanz.0 und dann auf 400 MB.
Beim start werden alle Objekte und States einmal gelesen (1,5GB).Dan wird vermutlich der Speicher, der für lesen benötigt war freigegeben (400MB). Dann sollte aber es konstant bleiben.
1.5GB… wie viel Objekte hast du?
Man kann "_id" in objekts.json zählen. `
3.256 Objekte
Momentan bleibt der Speicherverbrauch bei 1,5 GB für die Instanz .0. (nur admin und javascript.0 aktiv).
Habe eigentlich kaum was laufen gehabt (35 Adapter in der Grundeinrichtung und einige SQL-Monitorpunkte). Ich war ja gerade bei derNeueinrichtung, als es passierte. Alles frisch.
Ja, normalerweise geht der Speicher auf 400 MB runter oder auch mal auf 250 und schwankt dort hin und her. Ich hatte oben einige Beispiele als Grafik drin.
-
Hab den Übeltäter wahrscheinlich gefunden. @Bluefox: Deine Erklärungen waren sehr hilfreich.
Da das System vorher perfekt lief und das Problem anfing, als ich ein Miniänderung an einem Skript vorgenommen habe, hab ich vermutet, dass es sich ggf. um ein Objekt innerhalb javascript.x handeln könnte, was beim Einlesen Probleme macht.
Also habe ich angefangen die Datenpunkte in javascript.x nach und nach zu löschen und jeweils den Adapter neu zu starten.
Dabei bin ich auf einen Zweig in javascript.0. gestossen, der sich in Admin/Objekte nicht aufklappen lies und den Tab im Chrome zum Absturz gebracht hat. Innerhalb dieses Zweigs gibt es neun Datenpunkte, die ich aus den objects.json zum analysieren raus kopiert habe. Es handelt sich dabei die Datenpunkte eines alten Skripts für eine Ereignisliste.
Meine states.json ist über 200 MB groß und lässt sich in meinem JSON-Editor auf dem Mac nicht öffnen, was auch auf ein Problem innerhalb des JSON hinweist.
Ich werde jetzt versuchen, die entsprechenden States innerhalb der states.json mit einem Texteditor raus zu kopieren. Mein Editor kämpft gerade aber auch mit der Datei
Was ggf. Optimierungsmöglichkeiten für den Javascript-Adapter bietet:
-
Die einstellbare Speichergrenze in den Instanzen scheinen nicht zu greifen
-
ggf. kann der Adapter die Objekte prüfen und so ein Speicherproblem dann beim Einlesen verhindern
Danke für Deine Geduld!
Mir war wichtig die Ursache zu finden. Eine Neuinstallation wäre für mich schneller gewesen und hätte mich nicht die letzten zwei Wochen gekostet (der Kampf mit den beiden betroffenen Systemen). Danke noch einmal.
Ich versuche zu den Objekten noch die States zu isolieren und wenn es OK ist, schicke ich Dir die neun Datenpunkte. Vielleicht kannst Du ja was einbauen, was einen Totalabsturz verhindert
8-) -
-
Hab den Übeltäter wahrscheinlich gefunden. @Bluefox: Deine Erklärungen waren sehr hilfreich.
Da das System vorher perfekt lief und das Problem anfing, als ich ein Miniänderung an einem Skript vorgenommen habe, hab ich vermutet, dass es sich ggf. um ein Objekt innerhalb javascript.x handeln könnte, was beim Einlesen Probleme macht.
Also habe ich angefangen die Datenpunkte in javascript.x nach und nach zu löschen und jeweils den Adapter neu zu starten.
Dabei bin ich auf einen Zweig in javascript.0. gestossen, der sich in Admin/Objekte nicht aufklappen lies und den Tab im Chrome zum Absturz gebracht hat. Innerhalb dieses Zweigs gibt es neun Datenpunkte, die ich aus den objects.json zum analysieren raus kopiert habe. Es handelt sich dabei die Datenpunkte eines alten Skripts für eine Ereignisliste.
Meine states.json ist über 200 MB groß und lässt sich in meinem JSON-Editor auf dem Mac nicht öffnen, was auch auf ein Problem innerhalb des JSON hinweist.
Ich werde jetzt versuchen, die entsprechenden States innerhalb der states.json mit einem Texteditor raus zu kopieren. Mein Editor kämpft gerade aber auch mit der Datei
Was ggf. Optimierungsmöglichkeiten für den Javascript-Adapter bietet:
-
Die einstellbare Speichergrenze in den Instanzen scheinen nicht zu greifen
-
ggf. kann der Adapter die Objekte prüfen und so ein Speicherproblem dann beim Einlesen verhindern
Danke für Deine Geduld!
Mir war wichtig die Ursache zu finden. Eine Neuinstallation wäre für mich schneller gewesen und hätte mich nicht die letzten zwei Wochen gekostet (der Kampf mit den beiden betroffenen Systemen). Danke noch einmal.
Ich versuche zu den Objekten noch die States zu isolieren und wenn es OK ist, schicke ich Dir die neun Datenpunkte. Vielleicht kannst Du ja was einbauen, was einen Totalabsturz verhindert
8-) `
Es ist toll zu hören, dass du weiter gekommen bist.> Die einstellbare Speichergrenze in den Instanzen scheinen nicht zu greifen
Es wird eine Einstellung vorgenommen, die heißt "–max-old-space-size".Es kann sein, dass die nur für 0.10 und 0.12 gültig ist.
Und das habe ich noch gefunden:
"
Keep in mind that --max-old-space-size specifies the heap limit for the v8 JS engine that powers Node.js. This doesn't include all the memory the process might be using, such as buffers (for example, if you load very large images or JSON files). OSX will show you the entire memory usage of the node process in its activity monitor. Use process.memoryUsage() programatically to see heap memory usage."
-
