IoBroker.vis Android App
-
Danke Thorsten ,
Ich dachte schon, dass ich etwas falsch gemacht habe
Dauert bei mir auch nur etwa 20 sec.
Den Rest habe ich aber nicht verstanden.
@dtp:Wenn ich übrigens vom Vollbild wieder zurück will, dann muss ich die App neu starten, damit die Einstellung übernommen wird `
Jede Änderung der Einstellungen über ok wird ddoch mit einem Neustart beendet.@dtp:nach einem Neustart (egal, ob Vollbild eingestellt ist, oder nicht) immer die obere Statusleiste ausblendet. `
Ja ist so (jetzt habe ich es auch verstanden.) Ist doch gut. Dadurch hast du mehr Nettoplatz für die Views.Gruß
Rainer
-
OK, spannend….warum synct er sich dann bei mir "zu Tode"?....
Naja, ist nicht tragisch, da meine Views fertig sind und die ein, zwei neuen Aktoren pro Monat sind halt ein resyc über Nacht und fertig!
Grüße
etv
-
Bei mir dauert der resync auch ewig, schau doch mal, wie stark iobroker deinem Server belastet.
Gesendet von meinem HUAWEI CRR-L09 mit Tapatalk
-
…ja das könnte ich beim nächsten Sync nachschauen....danke!!
-
Hey again,
also ich habe mich jetzt die letzten zwei Tage wieder mit der App beschäftigt, bei mir funktioniert der Resync definitiv nicht so wie er soll.
Mein main Projekt resynct jetzt schon 24h und es ändert sich nichts, nur der graue Balken steht.
Ich habe auch ein neues Projekt angelegt mit nur einem Widget drinnen, das wird auch nicht gesynct.
Die App verhält sich auch irgendwie komisch, manchmal funktioniert sie ganz toll, ist schnell und alles, dann wieder braucht sie ewig wenn man damit was einschalten will… oder damit was geschaltetes angezeigt wird.
Ich werden den Resync der schon 24h läuft, nochmals solange laufen lassen und hoffen, dass sich was ändert. Nur ein Resync der 48h dauert ist mir ein bisschen zu lange :(, falls es überhaupt geht.
Das Ganze ist auf 3 verschiedenen Geräten das Selbe.
Die einzige Alternative die ich im Moment noch sehe, ist iobroker komplett neu zu installieren und zu sehen, ob sich da was ändert
-
Update.
Es funktioniert mit dem Resync… und das ziemlich schnell.
Ich habe ein paar Adapter deinstalliert die ich nicht unbedingt benötigte wie: node-red, simple terminal und mobile.
Dannach meinen Server neu gestartet und siehe da, auf einmal geht's (den Server hatte ich vorher auch schon einige Male neu gestartet)
Keine Ahnung was da alles mitspielt :?
-
Hallo Zusammen,
also, ich beobachte diese Unterhaltung nun schon länger, da bei mir momentan auch einiges nicht rund läuft. Insbesondere ist alles massiv langsam bis nicht mehr brauchbar geworden. Dieses aber nicht nur bei der App sonder allgemein alles.
Was ich als Fehlerquelle identifizieren konnte ist der "iobroker simple web adapter" der sich massiv an Speicher bedient und meinen Raspberry leer lutscht (unter 8% freier Speicher).
Was läuft hier falsch? Es dauert nur wenige Minuten und der Speicherbedarf des Web Adapters ist auf über 130MB gestiegen, er steigt mit zunehmender VIS App Nutzung! Es wird aber kein Speicher mehr frei gegeben.
Wer kann hier Helfen, bzw. hat gleiches beobachtet?
Danke und Gruß
-
@coronaxxl:Was ich als Fehlerquelle identifizieren konnte ist der "iobroker simple web adapter" der sich massiv an Speicher bedient und meinen Raspberry leer lutscht (unter 8% freier Speicher).
Was läuft hier falsch? Es dauert nur wenige Minuten und der Speicherbedarf des Web Adapters ist auf über 130MB gestiegen, er steigt mit zunehmender VIS App Nutzung! Es wird aber kein Speicher mehr frei gegeben.
Wer kann hier Helfen, bzw. hat gleiches beobachtet? `
Hallo coronaxxl,
geht bei dir der Speicherbedarf des web-Adapters durch die Nutzung der Android-App hoch?
Welche socket-IO-Verbindung verwendest du denn?
Den integrierten socket-IO des Web-Adapters oder den separaten? Wenn der separate socket-IO-Adapter verwendet wird, gibt es für den Speicheranstieg keinen Grund, weil dann die komplette Kommunikation über diesen läuft.
Zum allgemeinen Problem:
Der Anstieg des Web-Adapters bei Nutzung ist normal. Normalerweise erfolgt die Bereinigung automatisch durch node.js, wenn bestimmte Grenzwerte erreicht sind. Hier spielt die node.js Version eine entscheidende Rolle. Welche Version von node.js hast du denn im Einsatz?
node.js 4.0 läuft eigentlich auch ohne Optimierungen stabil, wird aber auf jedem System mit weniger als 2 GB irgendwann den meisten Speicher aufgebraucht haben, weil jeder Prozess per Default 256 MB old Space haben darf und die Bereinigung erst dann startet, wenn der Wert erreicht ist oder (ab 4.x) der freie Speicher allgemein knapp wird.
Man kann die Grenzwerte über die admin-Seite auch aktiv beeinflussen. Gehe mal auf der admin Instanzen-Seite und aktiviere die Experten-Einstellungen. Jetzt sollte rechts die Spalte RAM-Limit angezeigt werden. Gib da mal für den Web-Adapter 50 ein.
Dies ist aber keine harte Grenze, sondern nur der Wert, bei dem die Garbage Collection für diesen Prozess gestartet wird. Wenn der Prozess mehr Speicher braucht, steigt der Wert unter RAM-Benutzung trotzdem.
-
Hallo nobody,
Ich versuche jetzt auch in den letzten Tagen irgendwie einen Zusammenhang zwischen der Load average 5 und irgendeiner Ursache zu finden.
Lustiger Weise kann ich einen freien RAM von nur 40MB haben und trotzdem bleibt die Load über bestimmt eine Viertel Stunde unter 0,1!
Andererseits habe ich 150-290 MB freien RAM und trotzdem geht die Load über 2, was dann alles ausbremst.
Danke für die Info mit der Begrenzung des Speichers. Ich hatte mich da nicht getraut etwas kleineres einzustellen.
Mir ist noch weiteres seltsames in diesem Zusammenhang aufgefallen.
Ich hatte irgendwann mal eine ganze Zeitlang ein freies RAM von ca. 200MB, daraufhin hatte ich gedacht da ist noch mehr drin, habe einige Instanzen gelöscht und einen Reboot des RasPi gemacht.
Danach waren eine halbe Stunde nur noch 45MB frei.
Ein iobroker restart brachte den Wert dann immerhin wieder auf 145MB.
Manchmal startet nach einen Reboot der socketio nicht mehr weil er als letzte Instanz nicht mehr genug Speicher zur Verfügung hat. Soll 35 ist 30. Auch das bleibt über Minuten.
Eine weitere Sache ist mir noch aufgefallen, das könnte aber mit der von dir angesprochenen Garbage collection zusammenhängen. Der node-red Adapter soll 35MB Speicher brauchen. Deaktiviere ich ihn werden sofort dauerhaft gut 90MB Speicher frei, die auch reproduzierbar wieder verschwinden, wenn der Adapter wieder aktiviert wird.
Beim hm-rega ist es ähnlich, da scheint es sich aber nach einiger Zeit halbwegs einzupendeln.
Ansonsten habe ich im Moment keine Ahnung woran diese aktuelle Situation dran festzumachen sein könnte.
Gruß
Rainer
-
Hallo nobody,
Ich nutze den separaten Socket-io Adapter und der node.js sollte der 10.22 sein.
Was mir heute aufgefallen ist, ist dass das System ohne hm-rega Adapter super läuft. Hier hatte ich mir die Einstellungen nochmals angeschaut und festgestellt, dass das polling auf 5sec. stand. Mir war so, dass hier der Wert mal auf 15sec. stand. Habe ich nun geändert und bislang, ca. 1std., läuft das System eigentlich rund.
Ich denke die Proplematik wird auch in einem anderen Thread gerade diskutiert, "CPU Auslastung. .."
Ich werde das weiter beobachten und das auch mit der von dir vorgeschlagenen Speicherbegrenzung probieren.
Danke erst einmal und Grüße
Gesendet von meinem SM-T530 mit Tapatalk
-
@coronaxxl:Hallo nobody,
Ich nutze den separaten Socket-io Adapter und der node.js sollte der 10.22 sein.
Was mir heute aufgefallen ist, ist dass das System ohne hm-rega Adapter super läuft. Hier hatte ich mir die Einstellungen nochmals angeschaut und festgestellt, dass das polling auf 5sec. stand. Mir war so, dass hier der Wert mal auf 15sec. stand. Habe ich nun geändert und bislang, ca. 1std., läuft das System eigentlich rund.
Ich denke die Proplematik wird auch in einem anderen Thread gerade diskutiert, "CPU Auslastung. .."
Ich werde das weiter beobachten und das auch mit der von dir vorgeschlagenen Speicherbegrenzung probieren. `
Hallo coronaxxl,
ich würde dir dringend empfehlen, auf eine node.js 4.x zu wechseln. Mit der 0.10.x und auch mit 0.12.x klappt die Garbage Collection bei erschöpften Hauptspeicher nicht. Das haben erst neuere Google V8-Engines gelernt. Die alten gehen bis zur konfigurierten Speichergrenze. Und die ist halt 256 MB, und zwar pro node.js-Prozess. Jeder Adapter, Controller und node-red starten separate node.js-Instanzen.
Das gerade der hm-rega hier besonders auffällt, ist eigentlich auch klar. Dieser pollt im eingestellten Intervall (Default 30 Sekunden) alle Systemvariablen von der CCU. Da werden sehr viele Variablen angelegt, die anschließend in die virtuelle Mülltonne wandern, aber erst durch die Garbage Collection freigegeben werden.
-
node.js sollte der 10.22 sein. `
Hast du noch Wheezy ?Nodejs sollte 4.xx sein. Die 0.10.22 war zu Wheezy Zeiten aktuell.
Gruß
Rainer
-
Sorry,
Habe 4.4.5, gerade nochmal lieber geschaut.
Gruß
Gesendet von meinem SM-T530 mit Tapatalk
-
Hallo Homoran,
Load und RAM haben nur indirekt was miteinander zu tun. Das eine ist die CPU Belastung und das andere Speicher. Wenn die Garbage Collection los läuft, steigt zwar auch kurzzeitig die CPU-Belastung aber mehr auch nicht.
Reden wir hier von freien RAM oder von verfügbaren RAM? Dies ist unter LINUX nicht das gleiche.
Wenn man sich die RAM-Belegung mit top abfragt, bekommt man ja eine ganze Menge an Werten.
z.B.
KiB Mem: 996732 total, 904036 used, 92696 free, 126608 buffers KiB Swap: 102396 total, 12004 used, 90392 free. 142756 cached MemVerfügbar sind hier sowohl free als auch buffers und auch der File Cache wird von Linux dynamisch angepasst.
Auch der rpi-Adapter unterscheidet ja zwischen available und free. Der Linux Kernel betrachtet freien Speicher als Verschwendung und verwendet diesen als Cache für Libs und Dateien. Erst wenn andere Prozesse den Speicher brauchen, wird der Cache wieder frei gegeben. Das kann man z.B. sehr schön beobachten, wenn man Updates mit npm oder apt-get einspielt. Dann geht der freie Speicher ziemlich weit runter, der verfügbare Speicher bleibt aber in etwa auf dem gleichen Niveau.
Hier mal meine Einstellungen:
Damit läuft mein pi2 nun schon seit 5 Tagen (letzte Update-Welle), hat ca. 360 MB verfügbaren Speicher, freier Speicher schwankt zwischen 50 und 100 MB. Das verändert sich aber auch in zwei Wochen Urlaub nicht wesentlich.
Nebenbei läuft auf demselben pi auch noch mysql (speicheroptimierte Konfig), Redis (für js-controller), apache2 als Reverse-https-Proxy für alle internen Systeme, webcams usw., openvpn, ziemlich viele automatisch laufende Skripte in note-red und Image-Resizer für alle Webcams in node-red.
Mich wundert immer wieder, wieviel die kleine Kiste wegsteckt…Aber wichtig ist auch, alles was ich nicht brauche, wird auch wieder deinstalliert. Auf einem Bastelrechner ist einfach das System irgendwann an der Grenze.
Was man aber sehr deutlich sieht, ist wie sich die Umstellung auf Redis positiv auf die CPU-Load ausgewirkt hat. Seit der Umstellung vor 5 Tagen sind Load und durchnittliche CPU-Frequenz deutlich gesunken.
Noch eine kleine Ergänzung zum Thema LOAD:
Die Load-Angabe von TOP bezieht sich auf einem CPU-Kern. 1.0 bedeutet, alle CPU-Slots eines Kerns sind belegt. Bei Werten über 1.0 gibt es einen Rückstau.
Der Pi hat eine Quad-Core-CPU. Somit bedeutet 100% CPU-Auslastung 4.0. Bei einer Load von 2.0 ist die CPU nur zu 50% ausgelastet. Wo ist das Problem mit Load-Werten größer 1.0?
-
Hallo nobody,
Danke für die ausführlichen Informationen.
Was Load angeht, war mir das theoretisch klar, aber..?
Ab einem Wert von ca.1, 2 für 5 Minuten average war ioBroker kaum noch zu bedienen.
Was CPU Auslastung angeht waren die Summe der werte in top etwa das 4fache der im Header angegebenen CPU Auslastung.
Heisst das, dass nodejs (oder die prozessorverwaltung des RasPi) nur einen Kern nützt und es daher zu dem Rückstau kommt?
Ich habe auch schöne Screenshots gemacht, aber erstens ist das vom Tablet sehr mühsam zum anderen würde es hier wohl den Rahmen sprengen.
Beim Speicher bin ich immer vom freien Speicher ausgegangen, obwohl eigentlichder verfügbare hätte genommen werden müssen, da dort die gesamten Reserven drin sind.
Allerdings wollte ich auch sehen, wann die Garbage collection greift.
In allem habe ich immer noch keine Ursache gefunden die zu der hohen Load führt. Zumal zeitgleich die CPU Auslastung immer noch sehr niedrig ist.
Gruß
Rainer
PS habe gerade die App v0.4.3 installiert. Läuft gefühlt deutlich schneller. Der Zoomwertwird auch als Wert angezeigt! Sehr gut! Jetzt müsste man den noch eingeben können. Dann tappen meine dicken Wurstfinger nicht mehr daneben.
-
Was Load angeht, war mir das theoretisch klar, aber..?
Ab einem Wert von ca.1, 2 für 5 Minuten average war ioBroker kaum noch zu bedienen.
Was CPU Auslastung angeht waren die Summe der werte in top etwa das 4fache der im Header angegebenen CPU Auslastung.
Heisst das, dass nodejs (oder die prozessorverwaltung des RasPi) nur einen Kern nützt und es daher zu dem Rückstau kommt?
Ich habe auch schöne Screenshots gemacht, aber erstens ist das vom Tablet sehr mühsam zum anderen würde es hier wohl den Rahmen sprengen.
Beim Speicher bin ich immer vom freien Speicher ausgegangen, obwohl eigentlichder verfügbare hätte genommen werden müssen, da dort die gesamten Reserven drin sind.
Allerdings wollte ich auch sehen, wann die Garbage collection greift.
In allem habe ich immer noch keine Ursache gefunden die zu der hohen Load führt. Zumal zeitgleich die CPU Auslastung immer noch sehr niedrig ist.
Gruß
Rainer
PS habe gerade die App v0.4.3 installiert. Läuft gefühlt deutlich schneller. Der Zoomwert wird auch als Wert angezeigt! Sehr gut! Jetzt müsste man den noch eingeben können. Dann tappen meine dicken Wurstfinger nicht mehr daneben. `
Hallo Homoran,
ist war nur raten, aber ich gehe mal davon aus, dass das System mit dem Swappen anfängt und die CPU auf die Mem-Pages wartet, die von der SD-Karte geladen werden. Also nicht die CPU ist unter Wasser, sondern das IO-System kommt nicht mehr hinterher.
node.js nutzt mehrere Threads, wenn die Anwendung mehrere Threads erzeugt oder unabhängige Objekte existieren. Unterschiedliche node.js-Prozesse sind per se parallelisierbar.
Das was nicht parallelisierbar ist, ist der Prozess der Garbage Collection. Da dieser nach dem Stop-The-World Modell arbeitet, warten auch alle anderen Threads im gleichen node.js-Prozess, bis diese beendet ist.
Ich hab mal in einem anderen Thread geschrieben: wenn ein System im Normalbetrieb mit dem Auslagern von Speicherseiten von aktiven Prozessen anfängt, ist dieses aus meiner Sicht klinisch Tod. Der swap-Space ist nur gut für ungenutzte Libs oder inaktive Anwendungen.
Ich würde die Adapter soweit begrenzen, dass dies nicht mehr auftritt. Hast du dazu mal die RAM-Entwicklung der Adapter aufgezeichnet um zu erkennen, wer davon am meisten Speicher frisst?
Zur App:
Die Prozentangaben hat bluefox eingebaut.
Es sollte die Tastatur aufgehen, wenn man direkt auf die Zahl klickt.
Der Fortschrittsbalken beim Synchronisieren sollte jetzt auch funktionieren. Aber nicht wundern: Dieser wird zum Ende hin mehrfach wieder reduziert, weil die Bilder in anderen Ordnern als dem Projektverzeichnis erst zum Schluss aus den Views gelesen und zugefügt werden.
Neu ist:
Es sollten jetzt ebenfalls Bilder zur Laufzeit in den folgenden Widgets auf den lokalen Pfad geändert werden: JSON Tabelle, string img src und string unescaped. Ich hab mir die App-Version aus dem Play-Store noch nicht angeschaut. Es gab noch einen kleinen Fehler auf github, weswegen die Widgets string img src und string unescaped nicht korrekt angezeigt wurden. Wenn dies in der App (0.4.3) noch so ist, wird dies mit dem nächsten Update korrigiert.
-
dass das System mit dem Swappen anfängt und die CPU auf die Mem-Pages wartet, die von der SD-Karte geladen werden. Also nicht die CPU ist unter Wasser, sondern das IO-System kommt nicht mehr hinterher. `
In die Richtung ging auch mein Verdacht.Benutzter Swap Speicher war zuletzt 12 kiB. Nach dem deaktivieren von einigen Instanzen war das 0!
Leider habe ich keinen Datenpunkt gefunden für readdata oder writedata. Alles andere existiert.
Edit:
Habe gerade noch einen Screenshot von einem "schweren Ereignis" gefunden.
Swap war hier tatsächlich mal wieder in Benutzung.Und nodejs hängt das n der Warteschleife.
Die aktuelle und die 5 Minuten Loadsind schon erheblich.
Hast du dazu mal die RAM-Entwicklung der Adapter aufgezeichnet um zu erkennen, wer davon am meisten Speicher frisst? `
Leider nein. Welcher Datenpunkt wäre das?Wenn ich mal endlich Zeit finde würde ich gerne die identische Installationauf pi2, pi3 und auf cubietruck installieren und mal sehen was 2GB RAM btw. Die unterschiedliche Hardware ausmacht.
Es sollte die Tastatur aufgehen, wenn man direkt auf die Zahl klickt `
Njet!Der Fortschrittsbalken beim Synchronisieren sollte jetzt auch funktionieren. `
Jepp, in babyblauAußerdem sagt er beim resync: no Views found in null
Läuft trotzdem.
Gruß
Rainer
-
Die einfachste Art die Speichernutzung der Adapter aufzuzeichnen wären die Datenpunkte unter system.adapter {adapter-name}.0.memHeapTotal und system.adapter.{adapter-name}.0.memHeapUsed. Ist zwar nur der Heap, aber der ist normalerweise auch das, was anwächst.
Die System-Objekte sieht man nur, wenn man die Experteneinstellung einschaltet. Die paar KiByte Swapnutzung werden es aber nicht gewesen sein. Da müssen schon ein paar hundert MB ausgelagert gewesen sein. Das System lagert ungenutzte Libs auch aus, wenn der RAM nicht knapp ist. Es ist somit nicht unbedingt direkt ein Problem vorhanden, wenn es hier einen kleinen Wert > 0 gibt.
Was im Screenshot auffällt, ist der hohe Virtual-Wert der Influx-DB. Der ist um ein vielfaches höher, als der von mysql. Mit InfluxDB hab ich selbst noch nicht gearbeitet. Aber die erfohlenden Systemanforderungen passen eigentlich nicht zum pi2/3 (https://docs.influxdata.com/influxdb/v0 … d-more-ram). Schon garnicht, wenn neben influxDB noch anderes auf dem System läuft.
Was mich auch sehr wundert ist, der Prozess mit dem Namen nodejs . Dieser taucht normalerweise nur auf, wenn ein Prozess gerade neu gestartet wird.
Zur App:
Ich hab die App auf 1 Smartphone mit Android 6, einem Smartphone mit Android 4.4. x, einem Tablet mit Android 4.4.x und dem Android-Simulator mit Nexus 10 getestet.
In allen Geräten bekomme ich eine kleine Zahlentastatur, wenn ich direkt auf den Prozentwert klicke.
Auch klappt da der resync mit diversen Projekten ohne Fehler. Was hast du denn für ein Endgerät?
-
Nach Neustart des Tablets geht jetzt bei mir auch die Tastatur auf.
memheap total und used hatte ich schon gefunden, wusste aber nicht wirklich wofür die sind.
influxDB habe ich installiert, weil Bluefox meinte, das sei für ioBroker Ressourcenschonender als sql.
Vielleicht ich da auch was falsch verstanden.
Mir fiel eben außerdem auf, dass die Summe der CPU Nutzung in der Spalte, etwa das vierfache dessen ist, was im Kopf steht.
Mal sehen wie ich jetzt weiter vorgehe. Vielleicht liegt es ja auch am raspi3.
Gruß
Rainer
-
Hallo Bluefox,
danke für den Ladebalken!!
Aber….in der neuen Version von heute (17.7.) sind nun die iCal Adapter Einträge futsch....im Browser sehe ich sie, in der App nicht....
Grüße
Tom
