Hallo
Seit dem letzten Update auf IP-Symcon 4.10, 21.11.2016, b722c6df0013 (Windows) ist der CPU Verbrauch der lokalen Console (ips_console.exe*32) bei mir extrem hoch (CPU Last liegt bei ca.45%).
Auch die Ansicht bei sich ändernden Variablen ist extrem träge.
Wenn ich die Console minimiere fällt die CPU Last aber sofort wieder, beim Maximieren ist wieder ein starker Anstieg zu sehen…
Kann das noch wer bestätigen?
Danke und lg
Christian
Bisher nicht. Hast du vielleicht viele Variablen die sich pro Sekunden ändern?
paresy
Stimmt, habe ich schon, aber das hatte ich vorher auch…
Bei mir ist das auch so. War vor der 4.1 nicht so und mehr Variablen oder ähnliches habe ich auch nicht.
Was hat sich denn bei der 4.1 in der Console geändert im Gegensatz zur vorherigen Version?
Schöne Grüße,
Dennis
Auch ich kann die hohe CPU-Last bei geöffnetem Objektbaum bestätigen.
Solange nur das Meldungsfenster geöffnet ist, bleibt die CPU-Last im üblichen Bereich.
In diesem Zustand läuft die Konsole auch langfristig einwandfrei.
Sobald der Objektbaum angezeigt wird steigt die CPU-Last stark an und nach einigen Minuten beendet sich die Konsole mit der Fehlermeldung: „… Bereich der Nachrichten ist größer als Puffer …“. ( Fehlermeldung ist aus dem Gedächtnis wiedergegeben, daher sicherlich nicht 100% korrekt)
Bei mir läuft die 4.1 Beta unter wine-staging auf Ubuntu 16.04. Alles auf dem aktuellen Stand.
Gruß
Ralla
Mir ist noch etwas aufgefallen.
Wenn man den Wert einer Variablen in der Konsole manuell ändert, wird die Änderung nicht sofort angezeigt.
Weder erscheint die Änderung in der Tabelle innerhalb des Änderungsdialogs, noch wird die Wertänderung in der Baumansicht angezeigt.
Gruß
Ralla
P.S. Ich habe außer dem Update auf die 4.1 keine Änderungen vorgenommen. Unter der 4.0 traten diese Probleme nicht auf.
Ist bei mir auch so…
lg Christian
Zur Veranschaulichung mal ein paar Bilder.
Die sollen ja mehr als Worte sagen können.
Auf den Bildern sieht man:
Wenn das Meldungsfenster angezeigt wird, ist die, durch die Konsole verursachte, CPU-Last relativ gering. Die Zeiten im Meldungsfenster stimmen mit der Systemzeit und der im Webfront angezeigten Zeit überein. Alles Okay.
Wenn der Objektbaum angezeigt wird, steigt die CPU-Last sofort an. Würde man nun in das Meldungsfenster wechseln, würde man bemerken, dass die Zeiten im Meldungsfenster immer weiter hinter der Systemzeit und der im Webfront angezeigten Zeit zurückbleiben.
Nach ca. 10 Minuten crasht die Konsole.
Es wäre schön, wenn der Fehler zeitnah behoben werden könnte, so lässt sich nicht wirklich damit arbeiten.
Gruß
Ralla
Kann ich bestätigen - Habe genau das gleiche Verhalten.
Hier noch ein paar Daten zu meinem System:
Gruß
Benjamin
Hallo allerseits,
auch wenn es niemanden zu interessieren scheint, mach ich hier mal konstruktiv weiter.
Das Problem scheint mit der Darstellung der Baumstruktur des Objektbaums zusammenzuhängen.
Wenn ich den Objektbaum in der Listenansicht öffne läuft die Konsole einwandfrei. Zumindest eine halbe Stunde lang. 
Nach einer halben Stunde habe ich den Versuch abgebrochen, da der Absturz in der Regel deutlich früher passiert.
Selbst wenn ich die Listenansicht nach dem Aktualisierungszeitpunkt sortieren lassen, diese also ständig neu sortiert werden muss ( ich habe derzeit 1714 Variablen), steigt zwar die Last, die Konsole läuft jedoch weiter.
Kurz nach dem Umschalten auf die „Logische Baumansicht“ stürzt die Konsole mit der bekannten Fehlermeldung ab.
Was macht die Darstellung der Baumansicht was mehr Stress verursacht als das ständige Umsortieren der Listenansicht?
Gruß
Ralla
Leider kann ich die Console auch kaum noch sinnvoll nutzen. Bei mir bricht er auch immer wieder die Verbindung mit der bekannten Fehlermeldung ab. ("… Bereich der Nachrichten ist größer als Puffer …")
Auch wenn ich alle Events abschalte und kaum Last auf dem System ist bricht er regelmäßig die Verbindung ab.
Meine IPS Version: 4.10, 02.01.2017, 24c2d788c069 auf Ubuntu
Ich habe das auch von den Anderen beschriebene Problem mit der Console unter Win7 x86_64 als auch unter MacOS X und Fedora mit Wine.
Auch ein Rechtsklick auf ein Objekt in der Logischen Baumansicht funktioniert nicht immer, sondern das Popup kommt oft nur dann wenn man auf ein anderes Tab klickt. Unter Win7 scheint es mit dem Rechtsklick besser zu funktionieren als unter Wine. Aber auch hier passiert es.
Unter 4.0 war das nicht so. Wenn ich mir also den Changelog von 4.0->4.1 anschaue, fällt folgendes auf:
Verwaltungskonsole
Evtl. macht das „upgrade“ auf die neueste Delphi Version Probleme. Besteht die Möglichkeit die Console nochmal mit der „alten“ Version zu bauen?
Hoffe wir bekommen das Problem bald gelöst, so macht IPS einfach keinen Spass :-/
Schöne Grüße,
Dennis
So, ich hab gerade noch einmal geprüft, ob es nicht vielleicht doch an meiner Installation - defekter settings.json oder ähnlichem - liegt.
Ich habe also das komplette Verzeichnis „/var/lib/symcon“ von meinem Raspberry Pi 3, auf dem das aktuelle symcon 4.1 unter Jessie läuft, auf meinen alten Raspberry Pi 2b mit Wheezy und symcon 4.0 kopiert.
Das Ergebnis ist, dass „IP-Symcon 4.00, 20.10.2016, b2a4a4949374“ einwandfrei läuft.
Die CPU-Last der Konsole bleibt selbst mit geöffnetem Objektbaum unter 20% und es kommt zu keinem Absturz.
Vielleicht nimmt sich ja doch mal jemand der Sache an, auch wenn dieser Thread bisher von offizieller Seite nicht mal ignoriert wird.
Gruß
Ralla
Ich kann den Fehler bisher leider nicht nachstellen. Passiert das Problem auch bei einem frischen 4.1er System? Also ohne jegliche Objekte?
Steigt die CPU Last bei euch sofort, wenn man den Baum öffnet? Oder muss eine bestimmte Kategorie offen sein?
paresy
Hallo paresy,
danke für die Anregung es einmal mit einer frischen Installation zu versuchen.
Mit einer komplett neuen Installation bleibt die CPU Last niedrig.
Mit meiner bisherigen Installation steigt die CPU Last hingegen sofort nach dem Öffnen des Objektbaums in einer Baumansicht an.
Aufgrund dieser Beobachtung habe ich mich auf die Suche nach dem Schuldigen gemacht. Ich habe also nacheinander verschiedene Instanzen meiner bisherigen Installation deaktiviert bzw. gelöscht.
Es stellte sich heraus, dass die, von dem Modul „SymconHUE“ bereitgestellte, I/O-Instanz „Philips Hue Bridge“ in Verbindung mit Symcon 4.1 für das Problem der hohen CPU Last verantwortlich ist.
In Verbindung mit Symcon 4.0 tritt das Problem, wie gesagt, nicht auf.
Gruß
Ralla
P.S. Es reicht nicht das Ereignis „UPDATE“ zu deaktivieren. Die Instanz „Philips Hue Bridge“ muss gelöscht werden, erst dann sinkt die CPU Last.
<KORREKTUR>Diese Aussage kann ich so nicht aufrechterhalten. Siehe hier.</KORREKTUR>
Ich habe es noch einmal überprüft.
Ausgangspunkt war eine Neuinstallation von Symcon 4.1.
Unmittelbar nach der Installation ist die CPU Last der Konsole bei angezeigtem Objektbaum unauffällig.
Nach Installation und Einrichtung des Moduls „SymconHUE“ steigt die CPU Last sofort an.
Hallo,
bei mir tritt das gleiche Problem auf:
IP-Symcon 4.10, 02.01.2017, 24c2d788c069 mit Symcon HUE modul
IPSymcon und Konsole laufen auf verschiedenen Windows Rechnern (Win7-64). Das Problem tritt auch auf wenn man die Konsole lokal auf dem Server aufruft.
Interessanter Effekt:
In der Konsole wird der Objektbaum angezeigt (ob ausgeklappt oder nicht ist unerheblich). Solange man mit dem Mauszeiger im Konsolenfenster steht liegt die CPUlast bei 1-2%. Wenn man mit dem Mauszeiger das Konsolenfenster verlässt, d.h. er steht über dem Desktop oder in einer anderen Anwendung, steigt CPU-LAst auf 25%…
vielleicht hilft das…
Klaus
Ich mache zwar aktuell rechte viele Updates (welche ggf. noch nicht optimal sind), aber das es so eine Last verursacht??? Vor allem weil diese Funktionen nicht aufgerufen werden wenn das UPDATE nicht läuft. Aber das Problem besteht ja dann weiterhin.
Besteht das Problem auch, wenn man statt der Bridge alle Lampen und Kategorien löscht. (UPDATE muss natürlich deaktiviert sein!)
Ich hab es gerade mit einer neuen Symcon Installation getestet.
P.S. Es reicht nicht das Ereignis „UPDATE“ zu deaktivieren. Die Instanz „Philips Hue Bridge“ muss gelöscht werden, erst dann sinkt die CPU Last.
Diese Aussage muss ich revidieren. Wenn das Update deaktiviert ist sinkt auch die CPU Last auf ein normales Mass. Es dauert allerdings - selbst bei der ansonsten leeren Installation - erstaunlich lange. Wahrscheinlich war ich auf meinem produktivem System nicht geduldig genug.
Der Unterschied zwischen Baumansicht und Listenansicht fällt mit der Testinstallation auch nicht mehr ins Gewicht.
Es bleibt festzustellen, dass, wenn ich auf die 4.1 Testinstallation - die Warnung bzgl. des Versionsunterschieds ignorierend - mit der 4.0 Konsole zugreife, die CPU Last deutlich geringer ansteigt.
| Server | Konsole | Update | CPU Last |
|---|---|---|---|
| 4.1 | 4.1 | aktiv | ca 80% |
| 4.1 | 4.0 | aktiv | ca 15% |
| 4.1 | 4.1 | inaktiv | max 1% |
| 4.1 | 4.0 | inaktiv | max 1% |
Im Zusammenspiel mit der neuen Konsole gibt es offensichtlich jede Menge Reibung.
Gruß
Ralla
Hallo!
Ich habe kein HUE Modul im Einsatz, Problem besteht aber trotzdem.
lg Christian
Dann könnte es wirklich u.a. an den Updates liegen. Ich habe bei jedem ApplyData einige IPS_SetVariableProfile* drinne die ich noch in die Create umziehen wollte. Aber ob das alleine schon Grund ist k.a.
Auch werden bei jedem ApplyData alle Daten weggeschrieben. Was auch viele Messwerte generiert.
Hallo traxanos,
ich hatte zu dem Thema einen Bug-Report geschrieben, der zwischenzeitlich akzeptiert wurde.
Möglicherweise reagiert die 4.1 Konsole zur Zeit einfach etwas sensibel.
Gruß
Ralla
