Speicherverbrauch durch im Admin UI aufgeblähte Objekte
-
hier die ersten Zeilen von TOP.
PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL 782 root 20 0 123008 45424 9100 S 3,7 1,3 1:57.81 perl 757 iobroker 20 0 11,9g 873700 18004 S 0,7 24,4 1:10.28 iobroker.js-con 365 root 20 0 0 0 0 I 0,3 0,0 0:05.54 kworker/1:2-events 1339 www-data 20 0 271196 15248 12372 S 0,3 0,4 0:00.26 apache2 1563 iobroker 20 0 1790840 762564 19208 S 0,3 21,3 0:50.54 io.javascript.0 3106 root 20 0 13840 6452 3992 R 0,3 0,2 0:00.05 top 1 root 20 0 168268 8636 6348 S 0,0 0,2 0:01.27 systemd -
@homoran sagte in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:
@thomas_ sagte in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:
Hardware Model: NUC7CJYH
So einer liegt hier auch noch rum. Den habe ich vor Jahren schon aussortiert.
-
@thomas_ frisch gestartet?
und wirklich nichts mehr frei?
Da wäre top jetzt noch interessanter -
@thomas_ sagte in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:
hier die ersten Zeilen von TOP.
wenn's um Mem geht bitte auch danach sortieren
und vor allem den Header zeigen
-
@homoran das TOP ist von jetzt und er ist vor 2 Stunden neu gestartet. Das Bild ist immer das selbe.
Schau her:
thomas@xs35v3l:~$ free -m gesamt benutzt frei gemns. Puffer/Cache verfügbar Speicher: 3498 2628 664 1 441 869 Swap: 4095 2463 1632 thomas@xs35v3l:~$ iob stop thomas@xs35v3l:~$ free -m gesamt benutzt frei gemns. Puffer/Cache verfügbar Speicher: 3498 686 2605 1 442 2812 Swap: 4095 489 3606 thomas@xs35v3l:~$ iob start thomas@xs35v3l:~$ free -m gesamt benutzt frei gemns. Puffer/Cache verfügbar Speicher: 3498 1321 1866 1 545 2177 Swap: 4095 489 3606 thomas@xs35v3l:~$ free -m gesamt benutzt frei gemns. Puffer/Cache verfügbar Speicher: 3498 1581 1607 1 545 1917 Swap: 4095 489 3606 thomas@xs35v3l:~$ free -m gesamt benutzt frei gemns. Puffer/Cache verfügbar Speicher: 3498 1646 1538 1 548 1852 Swap: 4095 489 3606 thomas@xs35v3l:~$ free -m gesamt benutzt frei gemns. Puffer/Cache verfügbar Speicher: 3498 1727 1452 1 553 1770 Swap: 4095 489 3606 thomas@xs35v3l:~$ free -m gesamt benutzt frei gemns. Puffer/Cache verfügbar Speicher: 3498 2002 1177 1 553 1495 Swap: 4095 489 3606 thomas@xs35v3l:~$ free -m gesamt benutzt frei gemns. Puffer/Cache verfügbar Speicher: 3498 2129 1050 1 553 1369 Swap: 4095 489 3606 thomas@xs35v3l:~$ free -m gesamt benutzt frei gemns. Puffer/Cache verfügbar Speicher: 3498 2341 833 1 558 1157 Swap: 4095 489 3606 thomas@xs35v3l:~$ free -m gesamt benutzt frei gemns. Puffer/Cache verfügbar Speicher: 3498 2466 695 1 573 1032 Swap: 4095 489 3606 thomas@xs35v3l:~$ free -m gesamt benutzt frei gemns. Puffer/Cache verfügbar Speicher: 3498 2594 564 1 575 904 Swap: 4095 489 3606 thomas@xs35v3l:~$ free -m gesamt benutzt frei gemns. Puffer/Cache verfügbar Speicher: 3498 2698 458 1 578 800 Swap: 4095 489 3606 thomas@xs35v3l:~$ -
@thomas_ sagte in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:
Schau her:
das ist aber nicht der Header von
topund der RAM Verbrauch je Prozess ist da auch nicht zu sehen.
wenn sich schon controller + js adapter fast die Hälfte des RAM schnappen und auch der SWAP deutlich in Gebrauch ist, klemmt es
jetzt ist aber reichlich verfügbar in der diag waren es nur noch 3xxMB
-
@thomas_ sagte: ich habe 1181 Objekte...
Über 1,5 GB für die Javascript-Instanz: Da läuft offenbar mind. ein Skript Amok.
-
Es hüpft jetzt auf einmal ständig hin und her.
1,5 GB admin, dann 600 MB
javascript 40 MB, dann 1,5GB.Die anderen sehen vernünftig aus.
Die Javascripte sind nur zwei:
Das erste liest alle 5 Minuten eine URL aus, die eine Zahl ausspuckt und schreibt die Zahl auf den KNX Bus
Das zweite hat 5 ON-Events drin, aus dem Modus und würde auch die ins KNX schreiben, aber der Modbus Adapter ist ja deaktiviert - das tut also gar nichtsedit: das funktioniert auch alles, ich habe die history der objekte geprüft. da kommt nichts an. nicht, dass ihr denkt, meine skripte schreiben halt alle 2 ms nen neuen wert oder sowas ^^
PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL 7463 iobroker 20 0 1916916 1,1g 14768 S 1,0 31,5 0:40.20 iobroker.js-con 7504 iobroker 20 0 1383092 719332 14380 R 127,8 20,1 0:17.72 io.javascript.0 914 mysql 20 0 1887640 227456 9096 S 0,0 6,3 5:30.09 mariadbd 7589 iobroker 20 0 10,7g 143904 19692 S 0,0 4,0 0:03.89 io.rest-api.0 7488 iobroker 20 0 1759200 143072 10928 S 0,0 4,0 0:10.89 io.admin.0 7549 iobroker 20 0 1009312 137884 11872 S 0,0 3,8 0:02.40 io.tuya.0 -
jetzt hat es sich eingependelt
PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL 7488 iobroker 20 0 1723044 834036 22436 S 0,0 23,3 0:28.68 io.admin.0 7463 iobroker 20 0 1742872 822992 15616 S 0,7 23,0 0:52.81 iobroker.js-con 7504 iobroker 20 0 1744268 773680 19448 S 0,0 21,6 0:49.13 io.javascript.0 914 mysql 20 0 1822104 131300 11336 S 0,0 3,7 5:32.98 mariadbd 7549 iobroker 20 0 975860 61388 14352 S 0,0 1,7 0:03.06 io.tuya.0 7589 iobroker 20 0 10,7g 58580 12752 S 0,0 1,6 0:04.53 io.rest-api.0 7548 iobroker 20 0 690040 50564 15384 S 0,3 1,4 0:05.85 io.openknx.0 932 root 20 0 3538940 38364 12912 S 0,0 1,1 0:25.76 java 782 root 20 0 125268 37644 7940 S 4,0 1,1 3:47.61 perl 7570 iobroker 20 0 679596 34368 12472 S 0,0 1,0 0:01.87 io.discovery.0 -
@thomas_ das sieht dann wirklich nach einem amoklaufenden Skript aus, dass wahrscheinlich zeitgesteuert startet
-
iobroker neu gestartet mit deaktivierten Skripten.
Ergebnis:PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL 7904 iobroker 20 0 1484584 878440 15504 S 0,0 24,5 0:10.88 io.javascript.0 7859 iobroker 20 0 1884872 846588 15236 D 30,5 23,6 0:29.92 iobroker.js-con 7882 iobroker 20 0 1766296 745928 15296 S 0,0 20,8 0:10.92 io.admin.0 7940 iobroker 20 0 1009412 154080 15332 S 0,0 4,3 0:02.13 io.tuya.0 7994 iobroker 20 0 10,7g 129052 23408 S 0,0 3,6 0:02.66 node -
Wieso stehen denn da 103 Eingabewerte ganz ohne Skripte?
-
@thomas_ sagte in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:
iobroker neu gestartet
passt!
in ein, zwei Minuten sollte es weniger sein. -
@thomas_ weil der Adapter gerade alle states abonniert
aber 1,3 GB RAM kommt mir etwas viel vor -
ja, mir ja auch ^^
und weniger als 700 MB werden es nicht:
-
Jetzt hab ich es mal zum Test auf einem anderen debian Server installiert, der mehr RAM hat, aber der Verbrauch ist ja genau der gleiche:
2347370 iobroker 819.41 MiB io.admin.0 2347431 iobroker 76.58 MiB io.backitup.0 2351527 iobroker 865.33 MiB io.javascript.0 2351574 iobroker 76.55 MiB io.openknx.0 2347340 iobroker 1.42 GiB iobroker.js-controllerDann scheint das wohl so normal zu sein?
-
@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?
-
@marc-berg das ist beides ein frisch installierter iobroker
Der erste, kleinere PC, 4-5 Tage alt.
Bei dem zweiten Server habe ich im Prinzip nur die Objekte importiert. Aber sonst hab ich ja eh nichts am Laufen... CPU Auslastung ist ja auch Null. -
@thomas_ sagte in Hardware Voraussetzungen bzw. Speicherverbrauch iobroker:
das ist beides ein frisch installierter iobroker
nein!
da sind schon weitere Adapter installiert und aktiv -
Danke für euer aller Mühen, aber: so kommen wir ja nicht wirklich weiter.
Ich hatte auf einen wertvollen Tipp gehofft, von den iobroker Profis - mit dem Betriebssystem usw kenne ich mich ja selber aus. Kann doch nicht sein, dass ich der erste/einzige mit so einem Phänomen bin, dachte ich mir (wobei ich beim googlen auch nichts gefunden habe) - schließlich habe ich ja im Sinne des Systems kaum etwas eingerichtet. Offenbar gibt es auch keine weitergehenden Debug Möglichkeiten, sonst hätte sie wohl jemand schon genannt.
Inzwischen habe ich schon versucht, den controller mit den Chrome Dev Tools und einem SSH Tunnel remote zu debuggen, damit ich mal die Objektstrukturen und deren Speicherverbrauch anschauen kann, dann hätte ich mal in den Code schauen können und das Problem vielleicht so gefunden - aber beim Erstellen des Heap Snapshots bricht der iob Controller immer zusammen - ganz ohne Meldung, leider. Einmal hat er 89% geschafft.. Sehr seltsam.
Das Einzige, was bleibt, ist dann natürlich - wie immer bei Blackboxen - Trial & Error. Also alles nochmal von vorne neu einrichten und schauen, ab wann der Fehler kommt. Darauf scheint ihr jetzt auch hinaus zu wollen, lese ich heraus.
