Speicherbedarf CV

[ctr]

Mein produktives Visu Display war bis vor kurzem ein Acer Touchscreen Monitor mit eingebautem Android (DA241HL). Nun hat sich leider das Android auf dem Gerät verabschiedet und ich habe vor ein paar Monaten einen Compute Stick mit Windows gekauft (unter Android und Linux habe ich die Treiber für den Touchscreen nicht hinbekommen). Das lief nun eine Weile gut, mit Chrome im Vollbildmodus. Seit ein paar Wochen (CV aus GIT) verabschiedet sich jedoch Chrome regelmässig, weil der Arbeitsspeicher voll läuft. Es sind keine Plugins oder Erweiterungen installiert und es nur ein Tab mit der CV offen. Habe das auf die GIT Version geschoben und bin jetzt mal Testweise auf die letzte stable (0.10.2) und habe dort aber das gleiche Problem.

Der Compute Stick hat nur 2 GB RAM, davon stehen ohne Chrome noch 1,1 GB zur Verfügung. Beim erstmaligen Start von Chrome und Aufrufen der CV sind noch 500-700MB frei und dann kann ich mit der Zeit zugucken, wie der Speicher langsam voll läuft (ausschließlich der Bedarf des CV Tabs wird größer) und Chrome dann die Grätsche macht.

Ist das aus Prinzip so? Ein Chrome Problem? Oder haben wir evtl eine Art Memory Leak in der CV?
Konnte schon jemand etwas ähnliches beobachten?

[peuter]

Klingt auf jedenfall nach Memory Leak. Da das einzige was in Hintergrund was tut, die Verbindung zum Backend ist, wäre es noch interessant zu wissen, welches Backend Du einsetzt (openHAB, eibd, knxd?) und in welcher Version.
Und CV auf GIT bedeutet, Du hast die aktuellste Version aus dem Develop Branch genutzt? Als source oder build Version? Zwischen dieser und 0.10.2 bestehen nämlich durchaus große Unterschiede. Aber wenn es bei beiden Auftritt deutet auch das wiederum auf die Backend-Verbindung als Ursache hin, denn dort hat sich am wenigsten geändert.

[Chris M.]

Auch wenn OS und v.a. der Browser selbst für ein Memory-Leak wahrscheinlicher sein sollten, schließt das die CV ja nicht aus.
Was die CV noch unwahrscheinlicher macht (aber natürlich nicht ausschließt), ist das das letzte Release (0.10.2) und Git unter der Haube deutlich anders aussehen (wir sind von jQuery zu Qooxdoo gewechselt).

Probier doch mal in ungefähr dieser Reihenfolge ob und ab wann es ein Leak Problem gibt:

• Leere Config
• Demo-Config
• Deine Config ohne jegliche Plugins (hast Du schon, s.o. - aber evtl. findet ja jemand den Beitrag mit der Suche )
• Deine Config und alle GAs durch eine legalte Dummy-GA ersetzt, die sicher nicht am Bus verwendet wird
• Deine Config und alle GAs durch eine einzige ersetzt, die regelmäßig (minütlich) auf dem Bus auch vorbei kommt

Optimal wäre dabei mit den Chrome Entwicklertools nach Memory Leaks zu suchen, also wo sich der Speicher akkumuliert.

[ctr]

Danke für die Hinweise.
Keine Plugins bezog sich auf keine Chrome-Plugins, CV-Plugins nutze ich (wginfo, rsslog), kann ich aber mal testweise abschalten.
Als Backend setze ich knxd 0.10.0 ein.

Die GIT Version die ich vor der 0.10.2 eingesetzt habe, war vom Stand her auch pre-0.10 also noch ohne Qooxdoo, insofern vergleichbar.

Ich lasse jetzt einfach mal den Chrome Taskmanager mitlaufen um zu sehen in welchem Bereich sich der Speicherbedarf erhöht (falls man es sieht) und würde dann als nächster den Speicherprofiler mal mitlaufen lassen, obwohl ich nicht weiß, ob der lange genug mitmacht und wie man das Ergebnis liest.

Die Leeren und Demo Configs probiere ich anschließend.

[Chris M.]

Ich sehe gerade, mein Text war leicht missverständlich: bis einschließlich Versionen 0.10.x (also auch 0.10.2) ist noch "alte Welt" mit jQuery. Erst im Git, was dann mal 0.11 werden wird, ist auf Qooxdoo gewechselt.

Bei den CV-Plugins: Gerade das rsslog habe ich in Verdacht, dass da irgend etwas nicht optimal läuft - aber ich habe (noch) keinen Ansatz wo. Mir ist nur bekannt, dass man mit ein paar Instanzen den Server überlasten kann... (Ein offenes Browser-Tab mit meiner Visu und die beiden Touchpanels in der Wand kann das WireGate locker ab - aber wenn ich zusätzlich noch in einem Tab die rss-Demo laufen lasse wird's auf dem WireGate eng, v.a. wenn das Log schon mit vielen Einträgen befüllt ist). Aber eine Überlast am Server wäre auch unabhängig zum RAM Verbrauch am Client.