Speicherverbrauch durch im Admin UI aufgeblähte Objekte

? Offline

Jetzt seid nicht so zickig. Den Rest schaffe ich erst mal allein - ich halte euch auf dem Laufenden.

P.S.:
Und lasst meinen Mini PC in Ruhe. Der kann das ganz leicht ;) Hier soll ja keine Rakete gestartet werden.

Homoran

@thomas_ sagte in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:

Jetzt seid nicht so zickig.

hier ist keiner zickig!
Nur ohne Infos kann niemand helfen.
Und mehr als wiederholt nachfragen können wir nicht, auch wenn dann wieder keine Antwort kommt.

Die Deluxe Glaskugeln sind leider zu teuer für mich.

MartinP

@marc-berg said in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:

@thomas_

Dann scheint das wohl so normal zu sein?

Nein. Ich habe ca. die zehnfache Anzahl der Objekte, bei nur ca. einem Zehntel Speicherverbrauch.

Wie sieht der Speicher bei frisch installiertem ioBroker aus?

So ganz mag ich Dir das nicht glauben...

das wären ja bei

Oder: Braucht das eigentlich nackte iobroker schon über 3GB RAM?!

nur 300 MB für Deinen kompletten ioBroker ...

Mein noch langsameres System (siehe Signatur):

martin@iobroker-test-sicher:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:            6144        1986        2801           0        1356        4157
Swap:           6144          27        6116
martin@iobroker-test-sicher:~$

Kann das vielleicht davon abhängen, ob man die Datenpunkte / Stati intern im ioBroker speichert oder extern?

? Offline

@martinp kannst du mir bitte noch sagen, wie viel RAM bei dir der controller selber braucht? also der Prozess iobroker.js-con

MartinP

@thomas_

Tasks:  36 total,   1 running,  35 sleeping,   0 stopped,   0 zombie
%Cpu(s): 17.8 us, 10.4 sy,  0.0 ni, 67.4 id,  0.3 wa,  0.0 hi,  0.5 si,  0.0 st 
MiB Mem :   6144.0 total,   2829.1 free,   1955.0 used,   1359.8 buff/cache     
MiB Swap:   6144.0 total,   6116.6 free,     27.4 used.   4189.0 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                              
    366 iobroker  20   0   11.2g 368468  44928 S  10.3   5.9     13,27 iobroker.js-con                                      
    497 iobroker  20   0 1077368 211008  37760 S   6.6   3.4      7,29 io.sonoff.0                                          
    410 iobroker  20   0  998764 134272  37760 S   4.6   2.1      7,39 io.influxdb.0                                        
    429 iobroker  20   0 1025376 188608  43392 S   3.3   3.0 272:39.33 io.javascript.0

? Offline

Habe jetzt nebenbei angefangen, zu testen. Neu installiert und alles ist leer. Kein Adapter, nichts.

Martin hat ein laufendes System mit 362 MB Verbrauch beim controller.
Bei mir braucht der controller ganz nackt 255 MB.

43446 	iobroker 	118.77 MiB 	io.admin.0
43485 	iobroker 	78.56 MiB 	io.backitup.0
43503 	iobroker 	69.3 MiB 	io.discovery.0
43268 	iobroker 	255.23 MiB 	iobroker.js-controller

installiere ich dann nur den javascript Adapter, dann bin ich schon bei 452.

43446 	iobroker 	126.75 MiB 	io.admin.0
43485 	iobroker 	79.01 MiB 	io.backitup.0
43503 	iobroker 	70.32 MiB 	io.discovery.0
44706 	iobroker 	136.44 MiB 	io.javascript.0
43268 	iobroker 	452.73 MiB 	iobroker.js-controller

nach Installation von openknx sieht es so aus

43446 	iobroker 	126.69 MiB 	io.admin.0
43485 	iobroker 	78.87 MiB 	io.backitup.0
43503 	iobroker 	70.79 MiB 	io.discovery.0
44706 	iobroker 	137.16 MiB 	io.javascript.0
45167 	iobroker 	74.15 MiB 	io.openknx.0
43268 	iobroker 	428.2 MiB 	iobroker.js-controller

nach dem Import der Gruppenadressen ändert sich nicht viel. nun 10XX Objekte.
RAM Auslastung gleich geblieben. So weit so gut!

Modbus installiert und dann gehts auf einmal stark nach oben im Controller und das bleibt auch so:

43446 	iobroker 	162.98 MiB 	io.admin.0
43485 	iobroker 	79.99 MiB 	io.backitup.0
43503 	iobroker 	71.31 MiB 	io.discovery.0
44706 	iobroker 	140.34 MiB 	io.javascript.0
45853 	iobroker 	71.99 MiB 	io.modbus.0
45402 	iobroker 	82.3 MiB 	io.openknx.0
45506 	iobroker 	81.64 MiB 	io.openknx.0
43268 	iobroker 	953.04 MiB 	iobroker.js-controller

Dann wollte ich eine Abkürzung nehmen und mein Backup einspielen, um modbus zu deinstallieren.
Das Backup konnte ich aber erst einspielen, nachdem die 4GB RAM von Amazon da waren...
Vorher: JavaScript heap out of memory (Das gesamte Backup ist ja ein einziges JSON Objekt. Hui)

Es liefen dann erst mal nur die drei:

4352 	iobroker 	941.7 MiB 	io.admin.0
4404 	iobroker 	74.42 MiB 	io.backitup.0
4326 	iobroker 	1.3 GiB 	iobroker.js-controller

Und nun habe ich erst modbus deinstalliert, dann alles andere, bis auf openknx. Aber keine Änderung mehr.

Es bleibt also offenbar nach Deinstallation von Adaptern noch was im Controller "liegen".
Und ob es an modbus alleine liegt, weiß ich jetzt auch nicht.

Hier steht er jetzt:

5200 	iobroker 	762.28 MiB 	io.admin.0
5303 	iobroker 	76.01 MiB 	io.backitup.0
5252 	iobroker 	82.54 MiB 	io.openknx.0
5151 	iobroker 	1.12 GiB 	iobroker.js-controller

Jetzt muss ich wieder von vorne anfangen aber meine Zeit für heute ist erst mal um :(

? Offline

Ich habs gefunden! Da ist irgendwo ein Bug in der Admin UI im Zusammenspiel mit dem SQL Adapter! Ziemlich sicher bei der Aktion "alle Zustände bearbeiten".
Und wahrscheinlich nur beim USERDATA Ast.

Habe mir die Backup Datei angesehen, dort hab ich es gesehen. Da steht in den ganzen Objekten folgendes drin.

Auf der Oberfläche steht es auch drin wenn man die die Objekte in der JSON Ansicht aufmacht.

Da sollte eigentlich einfach "debounce": 1000 stehen. Stattdessen wird dort eingetragen:

"debounce": [
          0,
          [
            0,
            [
              0,
              1000
            ],
            [
              0,
              1000
            ],
... 34 Millionen Zeilen (!!!) später ...
            [
              0,
              1000
            ],
            1000
          ],
          1000
        ]

? Offline

Jetzt bin ich insgesamt auf knapp 1 GB RAM runter. Und schon reicht er wieder, mein PC :spock-hand:

Homoran

@thomas_ sagte in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:

in der Admin UI im Zusammenspiel mit dem SQL Adapter!

hast du alle nodes in den Objekten aufgeklappt?

? Offline

@homoran

@homoran said in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:

@thomas_ sagte in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:

in der Admin UI im Zusammenspiel mit dem SQL Adapter!

hast du alle nodes in den Objekten aufgeklappt?

ja, habe ich. Alles states gefiltert, um einzutragen, dass sie geloggt werden sollen. aber anstatt der 1000 hat er bei jedem Objekt ein array aus 4 mio mal [0,1000] eingetragen. Aber nur im USERDATA Ast (14 Objekte) war es falsch. Im ganzen KNX Ast (1000 Objekte ca.) ist es überall richtig eingetragen worden.

Homoran

@thomas_ sagte in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:

ja, habe ich

das wäre schon mal die Erklärung für den admin.
Und wahrscheinlich abboniert die alle der js-Adapter bei jeder Änderung

@thomas_ sagte in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:

um einzutragen, dass sie geloggt werden sollen.

wie viele denn?

paul53

@thomas_ sagte: Stattdessen wird dort eingetragen:

Also nicht zu viele Objekte, sondern einige Riesen-Objekte, die in js-controller, Admin und JS-Instanz gepuffert werden.

? Offline

@homoran said in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:

das wäre schon mal die Erklärung für den admin.
Und wahrscheinlich abboniert die alle der js-Adapter bei jeder Änderung

Abonnieren wird er da wahrscheinlich nichts, aber die Meta Daten von den Objekten holt er sich anscheinend.
Wobei das aber auch nicht so toll ist - das hat er dann alles komplett dauernd im Speicher. Wofür? Es soll doch nur mein Skript ausgeführt werden, sonst nichts.
Macht nur den Speicher voll... Auch wenn kein Fehler da ist.

@homoran said in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:

wie viele denn?

bei 950. davon 14 in userdata, bei denen es schief ging. Das muss aber noch nichts heißen. Vielleicht wollte die Admin UI auch bei den anderen die 4 Mio Arrays eintragen, nur hat er vorher die Grätsche gemacht. Müsste gesucht werden, der Bug - ist ja nicht gerade unerheblich. Ich bekomme ihn gerade nicht mehr aus dem Stand hin.

Ich wollte jedenfalls, dass alle Objekte im SQL geloggt werden.

@paul53 said in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:

@thomas_ sagte: Stattdessen wird dort eingetragen:

Also nicht zu viele Objekte, sondern einige Riesen-Objekte, die in js-controller, Admin und JS-Instanz gepuffert werden.

ganz genau. es waren bei mir 14 Riesen Objekte.

paul53

@thomas_ sagte: alles komplett dauernd im Speicher. Wofür?

Ohne die Puffer (Objekte / Zustände) können die synchronen Funktionen (z.B. getState(id), getObject(id)) nicht ausgeführt werden.

? Offline

@paul53 said in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:

@thomas_ sagte: alles komplett dauernd im Speicher. Wofür?

Ohne die Puffer (Objekte / Zustände) können die synchronen Funktionen (z.B. getState(id), getObject(id)) nicht ausgeführt werden.

Habs mir eben noch einmal angeschaut, das Ding.
Ich glaub eher, dass die Zustände da nicht gepuffert werden, sondern dass die Meta Daten für die Klickibunti Funktionen aka "Rules" gebraucht werden. Aber auch da könnte man sie nachher wieder abgeben, denn die Rules werden ja auch nur wieder zu JS Code.

Die Abfragen auf die Stati dürften direkt zum Backend durchgeleitet werden, hoffe ich, denn doppelte Speicherhaltung ist Käse. Weil sonst wenns mehr wird, wirds dann immer automatisch doppelt mehr. Oder stell dir vor, ich lege 10 Mio Objekte an. Und dann mache ich ein JS Skript, welches alle 2 Tage den Zustand des einen Objektes gleich dem Zustand des anderen Objektes setzt.
Bzw. beim Javascript Code muss man da gar nichts machen, denn der läuft ja alleine, ohne Gehhilfe. Wie dem auch sei. Ganze fast 1GB an Schrott wurden bei mir auch in die JS Engine permanent in den RAM übernommen (sogar ganz ohne Code) - und diesen Schrott mindestens, braucht sie nicht.

Aber alles nur Spekulation meinerseits, ich kenne die genaue Architektur natürlich nicht. Habe iobroker seit 4 Tagen.

? Offline

Wo bei meinen Tests weiter oben der RAM Spike nach der modbus Installation herkam, würde mich noch interessieren.
Da waren die Objekte noch nicht mit an Bord.

paul53

@thomas_ sagte: Die Abfragen auf die Stati dürften direkt zum Backend durchgeleitet werden

Das werden sie nur mit den asynchronen Versionen der betreffenden Funktionen (mit callback), denn der js-controller bietet keine synchronen Funktionen dafür. Für die synchronen Funktionen ist deshalb der Puffer erforderlich.

? Offline

@paul53 said in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:

@thomas_ sagte: Die Abfragen auf die Stati dürften direkt zum Backend durchgeleitet werden

Das werden sie nur mit den asynchronen Versionen der betreffenden Funktionen (mit callback), denn der js-controller bietet keine synchronen Funktionen dafür.

Ok wenn das so ist, dann trägt man den oben beschriebenen Rucksack

Homoran

@thomas_ sagte in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:

alle Objekte im SQL geloggt werden.

und wenn es "nur"

@thomas_ sagte in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:

bei 950

sind, ist das schon sehr viel.
ich bin ja schon ein Datenmessie, komme aber "nur" auf 340 States.

? Offline

@samson71 said in Speicherverbrauch durch im Admin UI aufgeblähte Objekte:

@thomas_ sagte in Speicherverbrauch durch im Admin UI aufgeblähte Objekte:

Den Titel habe ich eben erst verändert ;)

Und das auch recht reißerisch von der Wirkung her. Mutet nach vermeintlicher Feststellung von irgendwelchen "Unzulänglichkeiten" an.

ähm, das entspricht den Tatsachen. Es IST ein Fehler. Oder glaubst du, ich hab 4 Mio mal den Array da rein kopiert? Bitte.

Community Forum

NEWS

Speicherverbrauch durch im Admin UI aufgeblähte Objekte

Support us

880

32.5k

81.8k

1.3m