Speicherverbrauch/CPU-Last der Adminoberfläche
-
@sigi234 Huhu, ja, ich habe eine FritzBox und 6 weitere WLAN Access Points (alle angebunden via LAN) im Mesh. Oder ist das so falsch? Das hatte das Autodiscovery ergeben. Ich habe die Instanzen noch nicht genutzt und mich mit denen auch noch nicht beschäftigt. Reicht da eine für alle AVM Produkte?
@Worlik
Man sollte auch nur so wenig Zeuch wie möglich laufen haben. Wenn also Daten aus den einzelnen Adaptern nicht verwendet werden, schalt die aus. Gilt für den ganzen Zoo an Adaptern/Instanzen.
Das verringert auch die Last auf den Systemen. -
Ich habe bis auf tr-064.0 mal die anderen Instanzen gelöscht. Ich glaube aber noch nicht so recht, dass sich das Problem dadurch löst. Wenn es an den eingehenden Events der Objekte liegt (welche ja auch in der Adminoberfläche angezeigt werden), dann wird das nicht viel ändern (die tr-064 Instanzen hatten keine Objekte angelegt). Die restlichen Adapter nutze ich aber alle. Da ich ja gerade am Anfang bin, werden auch noch ein paar Geräte dazu kommen (22 Shellys liegen hier noch, 17 habe ich schon verbaut). Ich brauche auch noch weitere SayIt Instanzen, Präsenzmelder (via KNX), Temperatur/Feuchtesensoren (via KNX, MDT Glastaster II) und Fenstersensoren (Homematic wirds wohl werden).
Kann ich Clientseitig die Objektaktualisierung zu Debugzwecken mal irgendwie abschalten? Dann wüsste ich sicher, ob es damit zu tun hat oder nicht (also nur die Anzeige, nicht die tatsächlichen Zustände). Falls das nur via JavaScript-Konsole geht, das bekomme ich hin. ;)
-
Hallo,
ich wollte einmal nachfragen, ob es anderen auch so geht, dass der Speicherverbrauch der Adminoberfläche so enorm hoch ist. Viel schlimmer ist allerdings die nötige CPU-Leistung zur Anzeige der Oberfläche. Und ich meine damit nicht den Server, sondern der Client, welche die Adminoberfläche anzeigt.
Mein Desktop PC hat einen AMD Ryzen 7 3800X 8-Core Prozessor CPU, 64GB Arbeitsspeicher, eine GeForce 2700 Super und ist mit 2 Force MP600 SSD ausgestattet.
Öffne ich die Adminoberfläche in einem Browser meiner Wahl (ich habe Firefox, Opera, Chrome, Edge und den Internet Explorer ausprobiert), dann ist die Oberfläche in den ersten Minuten schnell und reagiert auch sofort. Nutze ich die Oberfläche nun einige Zeit, dann wird sie immer träger. Nach einigen Minuten erscheinen Eingaben dann nur noch mit einer Verzögerung von 1-2 Sekunden. Starte ich den Browser komplett neu, ist die Seite wieder einige Zeit schnell.
Mir ist nicht ganz klar, was das verursacht und ob ich alleine mit dem Problem bin. Vielleicht liegt es ja an irgendwelchen installierten Adaptern?
Diese hier sind zur Zeit installiert:
(unten sind nur web.0 und vis.0 nicht zu sehen).Der Speicherverbrauch und die Auslastung des Raspberry PI 4 B mit 8GB sind übrigens zu diesen Zeitpunkten nie auffällig (überprüft mit
topvia ssh).@Worlik sagte in Speicherverbrauch/CPU-Last der Adminoberfläche:
Mir ist nicht ganz klar, was das verursacht
der Browser!
-
Ich habe bis auf tr-064.0 mal die anderen Instanzen gelöscht. Ich glaube aber noch nicht so recht, dass sich das Problem dadurch löst. Wenn es an den eingehenden Events der Objekte liegt (welche ja auch in der Adminoberfläche angezeigt werden), dann wird das nicht viel ändern (die tr-064 Instanzen hatten keine Objekte angelegt). Die restlichen Adapter nutze ich aber alle. Da ich ja gerade am Anfang bin, werden auch noch ein paar Geräte dazu kommen (22 Shellys liegen hier noch, 17 habe ich schon verbaut). Ich brauche auch noch weitere SayIt Instanzen, Präsenzmelder (via KNX), Temperatur/Feuchtesensoren (via KNX, MDT Glastaster II) und Fenstersensoren (Homematic wirds wohl werden).
Kann ich Clientseitig die Objektaktualisierung zu Debugzwecken mal irgendwie abschalten? Dann wüsste ich sicher, ob es damit zu tun hat oder nicht (also nur die Anzeige, nicht die tatsächlichen Zustände). Falls das nur via JavaScript-Konsole geht, das bekomme ich hin. ;)
@Worlik sagte in Speicherverbrauch/CPU-Last der Adminoberfläche:
Die restlichen Adapter nutze ich aber alle.
Z. B. Ping und Discovery sind i.d.R. entbehrlich. Und bei genauerer Betrachtung mit Sicherheit auch noch andere.
-
@Worlik sagte in Speicherverbrauch/CPU-Last der Adminoberfläche:
Mir ist nicht ganz klar, was das verursacht
der Browser!
@Homoran Äh, naja, ich habe aber alle Browser durch. Ich bezweifle, dass es Lynx besser läuft :-) Safari und Konquerer kann ich noch testen. Denke aber wegen der Vielfalt der getesteten Browser nicht, dass das etwas ändert.
Die Frage wäre ja mal: Geht es jemand anders auch noch so? Verstärkt tritt das Problem übrigens auf, wenn man nebenbei Skripte offen hat und diese startet. Es passiert aber auch so nach einiger Zeit im Hintergrund.
Meint ihr echt, dass die paar Instanzen da den Kohl fett machen? Der Raspberry PI selbst langweilt sich nämlich absolut und hat gar keinen Stress mit den Instanzen. Die SD-Karte sieht auch unauffällig aus (Write/Read Tests haben erwartbare Werte).
@apollon77 Das geht ja hier schneller als in jedem Chat. ;) - also ist das Problem doch irgendwie bekannt? Interessant ist dabei, dass die einzelnen Browser ja nicht alle die selbe JavaScript Engine nutzen. Trotzdem passiert das in allen Browsern. Sprich die Garbage Collection funktioniert nicht, weil noch irgendwelche Variablen irgendwelche Objekte halten, die aber nicht mehr gebraucht werden?
-
@Homoran Äh, naja, ich habe aber alle Browser durch. Ich bezweifle, dass es Lynx besser läuft :-) Safari und Konquerer kann ich noch testen. Denke aber wegen der Vielfalt der getesteten Browser nicht, dass das etwas ändert.
Die Frage wäre ja mal: Geht es jemand anders auch noch so? Verstärkt tritt das Problem übrigens auf, wenn man nebenbei Skripte offen hat und diese startet. Es passiert aber auch so nach einiger Zeit im Hintergrund.
Meint ihr echt, dass die paar Instanzen da den Kohl fett machen? Der Raspberry PI selbst langweilt sich nämlich absolut und hat gar keinen Stress mit den Instanzen. Die SD-Karte sieht auch unauffällig aus (Write/Read Tests haben erwartbare Werte).
@apollon77 Das geht ja hier schneller als in jedem Chat. ;) - also ist das Problem doch irgendwie bekannt? Interessant ist dabei, dass die einzelnen Browser ja nicht alle die selbe JavaScript Engine nutzen. Trotzdem passiert das in allen Browsern. Sprich die Garbage Collection funktioniert nicht, weil noch irgendwelche Variablen irgendwelche Objekte halten, die aber nicht mehr gebraucht werden?
@Worlik sagte in Speicherverbrauch/CPU-Last der Adminoberfläche:
Die Frage wäre ja mal: Geht es jemand anders auch noch so?
Ja, ich leere dann mal einfach den Cache.
-
@Homoran Äh, naja, ich habe aber alle Browser durch. Ich bezweifle, dass es Lynx besser läuft :-) Safari und Konquerer kann ich noch testen. Denke aber wegen der Vielfalt der getesteten Browser nicht, dass das etwas ändert.
Die Frage wäre ja mal: Geht es jemand anders auch noch so? Verstärkt tritt das Problem übrigens auf, wenn man nebenbei Skripte offen hat und diese startet. Es passiert aber auch so nach einiger Zeit im Hintergrund.
Meint ihr echt, dass die paar Instanzen da den Kohl fett machen? Der Raspberry PI selbst langweilt sich nämlich absolut und hat gar keinen Stress mit den Instanzen. Die SD-Karte sieht auch unauffällig aus (Write/Read Tests haben erwartbare Werte).
@apollon77 Das geht ja hier schneller als in jedem Chat. ;) - also ist das Problem doch irgendwie bekannt? Interessant ist dabei, dass die einzelnen Browser ja nicht alle die selbe JavaScript Engine nutzen. Trotzdem passiert das in allen Browsern. Sprich die Garbage Collection funktioniert nicht, weil noch irgendwelche Variablen irgendwelche Objekte halten, die aber nicht mehr gebraucht werden?
@Worlik sagte in Speicherverbrauch/CPU-Last der Adminoberfläche:
Verstärkt tritt das Problem übrigens auf, wenn man nebenbei Skripte offen hat und diese startet.
wenn man an den Skripten arbeitet = editiert
Auch das ist bekannt, dass da der Browser Probleme macht, Cache leeren hilft auch da.@Worlik sagte in Speicherverbrauch/CPU-Last der Adminoberfläche:
Meint ihr echt, dass die paar Instanzen da den Kohl fett machen?
nein, das Backend hat damit -wie du im Eingangspost richtig festgestellt hast- nichts mit zu tun
-
@Worlik sagte in Speicherverbrauch/CPU-Last der Adminoberfläche:
Die Frage wäre ja mal: Geht es jemand anders auch noch so?
Ja, ich leere dann mal einfach den Cache.
-
Wenn ich mir das Ereignisprotokoll anschaue, dann kommen da sekündlich ~100 Wert rein. Da das in einer endlosen Tabelle gespeichert wird, wundert mich dann da gar nichts mehr. Ich habe den Reiter "Ereignisprotokoll" nun abgeschaltet. Ob das etwas bringt, werde ich dann sehen. Wenn ich die Oberfläche richtig verstehe, werden die zugehörigen Module der Menüpunkte auf der linken Seite erst beim ersten öffnen im DOM-Baum angelegt. Vermutlich bringt das also erstmal gar nichts.
Im Objektbaum werden unter Hierarchien geladen, wenn man sie das erste mal aufklappt. Klappt man sie wieder zu (entweder einzeln oder über den Knopf in der Toolbar) dann werden sie nur ausgeblendet, aber nicht aus dem DOM entfernt. Schlimmer noch: Aktualisierungen werden bei den zugeklappten Knoten weiterhin eingetragen, aber nicht etwa, indem man den Wert der einzelnen Zellen updatet, sondern offenbar durch entfernen der DOM-Knoten und anschließendes Neu einfügen.
Da wundert mich der Performance-Drop absolut nicht mehr. DOM-Knoten löschen und einfügen ist so ziemlich das schlimmste, was man in einer Webanwendung hinsichtlich der Performance tun kann. Ist das eine Sache des FancyTree oder worin liegt das begründet? Es handelt sich ja auch nicht um einen einzelnen DOM-Knoten je Wert sondern eher 30 Stück, weil zahlreiche ungeordnete DOM-Elemente entfernt werden.
Das erklärt auch den weiteren Bug, dass offene Editoren z.B. in der Spalte "Name" hart geschlossen werden, wenn ein neuer Wert rein kommt, während man den Namen anpasst.
Das erklärt aber erstmal nur die CPU-Last und noch nicht den Speicherverbrauch. Entfernte DOM-Knoten sollte der Browser freigeben. In anbetracht dessen, dass ich 64 GB habe und davon 80% frei sind, stört der Speicherverbrauch aber erstmal nicht. Ich habe auch eine Speicheranalyse im Webbrower probiert. Hier sieht man, dass zyklisch Speicher geholt, aber auch zurück gegeben wird. Einen großen Anstieg erzeugt das erstmalige öffnen des Skript Editors (was grundsätzlich zu erwarten und auch okay ist). Die CPU-Last ist aber ein No-Go.
-
Wenn ich mir das Ereignisprotokoll anschaue, dann kommen da sekündlich ~100 Wert rein. Da das in einer endlosen Tabelle gespeichert wird, wundert mich dann da gar nichts mehr. Ich habe den Reiter "Ereignisprotokoll" nun abgeschaltet. Ob das etwas bringt, werde ich dann sehen. Wenn ich die Oberfläche richtig verstehe, werden die zugehörigen Module der Menüpunkte auf der linken Seite erst beim ersten öffnen im DOM-Baum angelegt. Vermutlich bringt das also erstmal gar nichts.
Im Objektbaum werden unter Hierarchien geladen, wenn man sie das erste mal aufklappt. Klappt man sie wieder zu (entweder einzeln oder über den Knopf in der Toolbar) dann werden sie nur ausgeblendet, aber nicht aus dem DOM entfernt. Schlimmer noch: Aktualisierungen werden bei den zugeklappten Knoten weiterhin eingetragen, aber nicht etwa, indem man den Wert der einzelnen Zellen updatet, sondern offenbar durch entfernen der DOM-Knoten und anschließendes Neu einfügen.
Da wundert mich der Performance-Drop absolut nicht mehr. DOM-Knoten löschen und einfügen ist so ziemlich das schlimmste, was man in einer Webanwendung hinsichtlich der Performance tun kann. Ist das eine Sache des FancyTree oder worin liegt das begründet? Es handelt sich ja auch nicht um einen einzelnen DOM-Knoten je Wert sondern eher 30 Stück, weil zahlreiche ungeordnete DOM-Elemente entfernt werden.
Das erklärt auch den weiteren Bug, dass offene Editoren z.B. in der Spalte "Name" hart geschlossen werden, wenn ein neuer Wert rein kommt, während man den Namen anpasst.
Das erklärt aber erstmal nur die CPU-Last und noch nicht den Speicherverbrauch. Entfernte DOM-Knoten sollte der Browser freigeben. In anbetracht dessen, dass ich 64 GB habe und davon 80% frei sind, stört der Speicherverbrauch aber erstmal nicht. Ich habe auch eine Speicheranalyse im Webbrower probiert. Hier sieht man, dass zyklisch Speicher geholt, aber auch zurück gegeben wird. Einen großen Anstieg erzeugt das erstmalige öffnen des Skript Editors (was grundsätzlich zu erwarten und auch okay ist). Die CPU-Last ist aber ein No-Go.
-
@Worlik Wir nehmen gern PRs :-))) Admin 4.x ist inm Branch "4.0.x" ... master Branch ist der React Rewrite Admin 5.0 der in Entwicklung ist
@apollon77 Das freut mich natürlich zu hören. :-) Ich weiß noch nicht, ob ich etwas zum Code beitragen kann. NodeJS ist nicht meine Heimatwelt. Ich erstelle eher eigene Komponenten.
Gibt es das Problem in der nächsten Major denn dann nicht mehr?
-
@apollon77 Das freut mich natürlich zu hören. :-) Ich weiß noch nicht, ob ich etwas zum Code beitragen kann. NodeJS ist nicht meine Heimatwelt. Ich erstelle eher eigene Komponenten.
Gibt es das Problem in der nächsten Major denn dann nicht mehr?
@Worlik In dem Fall hat das ja alles nix mit Nodejs zu tun ... das ist Javascript im Browser :-)
Admin 4 ist JQuery und Material stuff ... Admin 5 wird React.
Ich denke wir brauchen erstmal was "fertiges" von Admin 5, dann kann man mal schauen, aber dadurch das quasi alles ein React rewrite ist ... vielleicht ;-)
-
@Worlik In dem Fall hat das ja alles nix mit Nodejs zu tun ... das ist Javascript im Browser :-)
Admin 4 ist JQuery und Material stuff ... Admin 5 wird React.
Ich denke wir brauchen erstmal was "fertiges" von Admin 5, dann kann man mal schauen, aber dadurch das quasi alles ein React rewrite ist ... vielleicht ;-)
@apollon77 so genau hatte ich noch nicht hingeschaut. 🙈 Freue mich aber natürlich schon mal darauf.
Heißt aber natürlich auch, bis zum Release bleibt das momentane Problem dann erst mal bestehen. Immerhin muss ich nun nicht weiter suchen.
-
@apollon77 so genau hatte ich noch nicht hingeschaut. 🙈 Freue mich aber natürlich schon mal darauf.
Heißt aber natürlich auch, bis zum Release bleibt das momentane Problem dann erst mal bestehen. Immerhin muss ich nun nicht weiter suchen.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden268
Online32.9k
Benutzer83.0k
Themen1.3m
Beiträge