Adapter beenden sich. Zu wenig RAM wg. js-controller?
-
Hallo.
ich habe heute festgestellt, dass einige Adapter (zunächst echarts, später history, dann weitere) nicht mehr korrekt oder gar nicht mehr liefen. Aufgrund eines aktuellen Topic über Probleme mit dem echarts Adapters und zu wenig RAM habe ich an dieser Stelle nachgeforscht. Ich habe 6 GB RAM 3,2 GB nutzt allein der js-controller, jeweils 1 GB Javascript und Admin. Das kommt mir doch recht hoch vor. Kann es sein, dass wirklich so viel RAM dafür benötigt wird oder habe ich die Ursache an anderer Stelle zu suchen. Was könnte die Ursache sein?
Versionen:
Adapter "javascript" : 7.0.3 , installed 7.0.3
Adapter "admin" : 6.8.0 , installed 6.8.0
Controller "js-controller": 4.0.24 , installed 4.0.24
Node.js v18.16.0@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
Was könnte die Ursache sein?
Vielleicht findet sich was in
iob diag -
@markusk sagte: 3,2 GB nutzt allein der js-controller, jeweils 1 GB Javascript und Admin.
Alle drei puffern sämtliche Objekte und Zustände (states). Wie viele sind es?
Das müssten dann um die 1.2 Millionen sein, das ist doch etwas heftig ...
-
Hallo.
ich habe heute festgestellt, dass einige Adapter (zunächst echarts, später history, dann weitere) nicht mehr korrekt oder gar nicht mehr liefen. Aufgrund eines aktuellen Topic über Probleme mit dem echarts Adapters und zu wenig RAM habe ich an dieser Stelle nachgeforscht. Ich habe 6 GB RAM 3,2 GB nutzt allein der js-controller, jeweils 1 GB Javascript und Admin. Das kommt mir doch recht hoch vor. Kann es sein, dass wirklich so viel RAM dafür benötigt wird oder habe ich die Ursache an anderer Stelle zu suchen. Was könnte die Ursache sein?
Versionen:
Adapter "javascript" : 7.0.3 , installed 7.0.3
Adapter "admin" : 6.8.0 , installed 6.8.0
Controller "js-controller": 4.0.24 , installed 4.0.24
Node.js v18.16.0@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
Ich habe 6 GB RAM 3,2 GB nutzt allein der js-controller, jeweils 1 GB Javascript und Admin.
nutzen sie das, oder stellt Linux diese Nenge nur vorsorglich zur Verfügung?
-
@markusk sagte: 3,2 GB nutzt allein der js-controller, jeweils 1 GB Javascript und Admin.
Alle drei puffern sämtliche Objekte und Zustände (states). Wie viele sind es?
@paul53
Objects: 17229
States: 13444Size of iob-Database:
37M /opt/iobroker/iobroker-data/objects.jsonl
8.2M /opt/iobroker/iobroker-data/objects.json.migrated
8.2M /opt/iobroker/iobroker-data/objects.json.bak.migrated
21M /opt/iobroker/iobroker-data/states.jsonl
2.5M /opt/iobroker/iobroker-data/states.json.migrated
2.5M /opt/iobroker/iobroker-data/states.json.bak.migrated -
@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
Ich habe 6 GB RAM 3,2 GB nutzt allein der js-controller, jeweils 1 GB Javascript und Admin.
nutzen sie das, oder stellt Linux diese Nenge nur vorsorglich zur Verfügung?
@homoran
Resident sind 2,3GBTasks: 167 total, 1 running, 166 sleeping, 0 stopped, 0 zombie %Cpu(s): 7.9 us, 1.0 sy, 0.0 ni, 90.5 id, 0.0 wa, 0.0 hi, 0.4 si, 0.2 st MiB Mem : 5962.5 total, 723.0 free, 4278.8 used, 960.7 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 1410.2 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 608 iobroker 20 0 3205316 2.3g 19156 S 18.1 38.7 10:18.75 iobroker.js-con 1204 iobroker 20 0 750256 75144 17396 S 7.7 1.2 1:39.73 io.history.0 2319 iobroker 20 0 699136 79280 20932 S 3.2 1.3 0:53.56 io.upnp.0 2912 iobroker 20 0 993876 320928 43728 S 2.8 5.3 2:14.41 io.javascript.0 1334 iobroker 20 0 700384 69540 16948 S 2.0 1.1 0:41.79 io.sonoff.0 16226 root 20 0 8484 3620 2888 R 0.8 0.1 0:00.04 top 1 root 20 0 169700 7468 4892 S 0.4 0.1 0:05.71 systemd 939 root 20 0 1468580 32732 4816 S 0.4 0.5 0:01.29 dockerd 1149 kress 20 0 15740 3528 1860 S 0.4 0.1 0:05.32 sshd 1250 iobroker 20 0 959676 76392 22072 S 0.4 1.3 0:12.97 io.telegram.1 1289 iobroker 20 0 706960 59156 16936 S 0.4 1.0 0:07.27 io.mihome-vacuu 1304 iobroker 20 0 960872 74328 16360 S 0.4 1.2 0:58.54 io.mqtt.0 2273 iobroker 20 0 950028 65372 22052 S 0.4 1.1 0:09.20 io.info.0 -
@homoran
Resident sind 2,3GBTasks: 167 total, 1 running, 166 sleeping, 0 stopped, 0 zombie %Cpu(s): 7.9 us, 1.0 sy, 0.0 ni, 90.5 id, 0.0 wa, 0.0 hi, 0.4 si, 0.2 st MiB Mem : 5962.5 total, 723.0 free, 4278.8 used, 960.7 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 1410.2 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 608 iobroker 20 0 3205316 2.3g 19156 S 18.1 38.7 10:18.75 iobroker.js-con 1204 iobroker 20 0 750256 75144 17396 S 7.7 1.2 1:39.73 io.history.0 2319 iobroker 20 0 699136 79280 20932 S 3.2 1.3 0:53.56 io.upnp.0 2912 iobroker 20 0 993876 320928 43728 S 2.8 5.3 2:14.41 io.javascript.0 1334 iobroker 20 0 700384 69540 16948 S 2.0 1.1 0:41.79 io.sonoff.0 16226 root 20 0 8484 3620 2888 R 0.8 0.1 0:00.04 top 1 root 20 0 169700 7468 4892 S 0.4 0.1 0:05.71 systemd 939 root 20 0 1468580 32732 4816 S 0.4 0.5 0:01.29 dockerd 1149 kress 20 0 15740 3528 1860 S 0.4 0.1 0:05.32 sshd 1250 iobroker 20 0 959676 76392 22072 S 0.4 1.3 0:12.97 io.telegram.1 1289 iobroker 20 0 706960 59156 16936 S 0.4 1.0 0:07.27 io.mihome-vacuu 1304 iobroker 20 0 960872 74328 16360 S 0.4 1.2 0:58.54 io.mqtt.0 2273 iobroker 20 0 950028 65372 22052 S 0.4 1.1 0:09.20 io.info.0@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
Resident sind 2,3GB
free sind nur 723MB, ist aber irrelevant. Available sind aber auch nur 1.4GB und das bei 8GB RAM!
Der Controller benötigt davon 18.1% = knapp 1.5GB
Das erscheint mir wirklich vieledit: sind ja nur 6GB RAM! ist trotzdem IMHO zu viel
-
@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
Resident sind 2,3GB
free sind nur 723MB, ist aber irrelevant. Available sind aber auch nur 1.4GB und das bei 8GB RAM!
Der Controller benötigt davon 18.1% = knapp 1.5GB
Das erscheint mir wirklich vieledit: sind ja nur 6GB RAM! ist trotzdem IMHO zu viel
@homoran sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
Resident sind 2,3GB
free sind nur 723MB, ist aber irrelevant. Available sind aber auch nur 1.4GB und das bei 8GB RAM!
Der Controller benötigt davon 18.1% = knapp 1.5GB
Das ist die CPU - MEM ist 38.7% = um die 2.3GB. Da läuft definitiv was falsch.
-
@paul53
Objects: 17229
States: 13444Size of iob-Database:
37M /opt/iobroker/iobroker-data/objects.jsonl
8.2M /opt/iobroker/iobroker-data/objects.json.migrated
8.2M /opt/iobroker/iobroker-data/objects.json.bak.migrated
21M /opt/iobroker/iobroker-data/states.jsonl
2.5M /opt/iobroker/iobroker-data/states.json.migrated
2.5M /opt/iobroker/iobroker-data/states.json.bak.migrated -
@homoran sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
Resident sind 2,3GB
free sind nur 723MB, ist aber irrelevant. Available sind aber auch nur 1.4GB und das bei 8GB RAM!
Der Controller benötigt davon 18.1% = knapp 1.5GB
Das ist die CPU - MEM ist 38.7% = um die 2.3GB. Da läuft definitiv was falsch.
@ticaki sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
Das ist die CPU - MEM ist 38.7% = um die 2.3GB. Da läuft definitiv was falsch.
ja, schief abgetippt!
und die CPU Last bezieht sich sogar nur auf einen Kern.
-
@markusk sagte:
Objects: 17229
States: 13444Das ist dann wohl nicht die Ursache.
Finden zu viele Ereignisse statt, die nicht mehr in Echtzeit abgearbeitet werden können und deshalb den Fifo füllen?Ich verstehe das hier wahrscheinlich zu viel RAM benötigt wird. Habe die meisten Adapter gestoppt (auch Javascript) und den IOB neu gestartet. Jetzt sind es nur noch 1GB, davon 280MB resident.
Starte ich den Javascript Adapter, werden 200MB vom Controller zusätzlich allokiert. Der Javascript benötigt weiterhin 1GB. Der Admin-Adapter bleibt bei 1GB. Starte ich einen Adapter nach dem anderen bis alle wieder laufen, beibt es bei 1,2GB für den Controller.
Der Backupitup benötigt 20GB, resident allerdings nur 100mb,
top - 13:46:41 up 2:15, 1 user, load average: 0.68, 0.56, 0.37 Tasks: 167 total, 1 running, 166 sleeping, 0 stopped, 0 zombie %Cpu(s): 7.7 us, 0.7 sy, 0.0 ni, 90.9 id, 0.1 wa, 0.0 hi, 0.5 si, 0.2 st MiB Mem : 5962.5 total, 2602.5 free, 2212.2 used, 1147.8 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 3472.7 avail Mem PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20 0 20.9g 99232 46632 S 0.0 1.6 0:03.85 io.backitup.0 20 0 1504560 21768 2980 S 0.0 0.4 0:02.55 containerd 20 0 1468580 32732 4816 S 0.0 0.5 0:02.05 dockerd 20 0 1200840 338080 43876 S 19.9 5.5 1:55.42 iobroker.js-con 20 0 1145932 318060 43904 S 2.6 5.2 0:50.45 io.javascript.0 20 0 1007220 153680 44948 S 0.7 2.5 0:21.56 io.admin.0 20 0 954216 86952 38624 S 0.7 1.4 0:13.44 io.mqtt.0 20 0 951908 89820 39704 S 0.0 1.5 0:11.79 io.alexa2.0 20 0 948748 82332 38936 S 0.0 1.3 0:03.64 io.hm-rega.0 20 0 948496 87524 38880 S 0.0 1.4 0:03.68 io.hue-extended 20 0 948428 84012 38768 S 0.0 1.4 0:03.79 io.tr-064.0 20 0 946544 79408 38944 S 1.3 1.3 0:04.33 io.enigma2.0 20 0 943632 76980 39840 S 0.0 1.3 0:04.73 io.bluelink.0 20 0 820924 90136 44560 S 0.0 1.5 0:02.73 io.telegram.1 20 0 820156 89392 44560 S 0.7 1.5 0:02.66 io.telegram.0 20 0 815116 78924 39612 S 0.3 1.3 0:05.23 io.info.0 20 0 811420 77508 39428 S 0.0 1.3 0:02.62 io.hm-rpc.0 20 0 760300 95876 39504 S 0.0 1.6 0:04.94 io.iot.0 20 0 751820 82864 38372 S 2.3 1.4 0:08.39 io.history.0 20 0 743324 71956 39396 S 0.0 1.2 0:02.48 io.hm-rpc.1 20 0 741764 71628 38996 S 0.0 1.2 0:01.69 io.fritzbox.0 20 0 705424 86316 44600 S 0.0 1.4 0:03.72 io.mihome-vacuu 20 0 701808 99300 38664 S 0.0 1.6 0:04.03 io.vis-2-beta.0 20 0 687236 82232 38568 S 0.0 1.3 0:02.41 io.nuki-extende 20 0 686816 82548 38340 S 4.3 1.4 0:04.20 io.sonoff.0 20 0 685612 81156 38492 S 0.0 1.3 0:03.91 io.web.0 20 0 684288 81192 38688 S 4.0 1.3 0:05.95 io.upnp.0 20 0 681348 75932 38436 S 0.0 1.2 0:04.82 io.simple-api.0 20 0 680840 75360 38728 S 0.0 1.2 0:02.21 io.harmony.0 20 0 678788 76176 39912 S 0.0 1.2 0:02.38 io.email.0 20 0 677508 72596 38320 S 0.0 1.2 0:01.74 io.discovery.0 20 0 677508 72808 38328 S 0.0 1.2 0:01.70 io.ping.0 20 0 677388 71440 38364 S 0.0 1.2 0:01.58 io.echarts.0Ich stoppe den iob und starte ihn erneut mit allen Adaptern. Das stoppen benötigt eine Minute. Nachdem alle Adapter wieder laufen, benötigt der Controller 1,3 GB, also etwas mehr wie beim einzelnen Starten. Die Adapter bleiben aber gestartet.
Den Server hatte ich vor allen Aktionen rebooted. D.h. den hohen Speicherbedarf hatte ich auch nach einem Reboot.
Verstehen tue ich das jedenfalls nicht.
-
Ich verstehe das hier wahrscheinlich zu viel RAM benötigt wird. Habe die meisten Adapter gestoppt (auch Javascript) und den IOB neu gestartet. Jetzt sind es nur noch 1GB, davon 280MB resident.
Starte ich den Javascript Adapter, werden 200MB vom Controller zusätzlich allokiert. Der Javascript benötigt weiterhin 1GB. Der Admin-Adapter bleibt bei 1GB. Starte ich einen Adapter nach dem anderen bis alle wieder laufen, beibt es bei 1,2GB für den Controller.
Der Backupitup benötigt 20GB, resident allerdings nur 100mb,
top - 13:46:41 up 2:15, 1 user, load average: 0.68, 0.56, 0.37 Tasks: 167 total, 1 running, 166 sleeping, 0 stopped, 0 zombie %Cpu(s): 7.7 us, 0.7 sy, 0.0 ni, 90.9 id, 0.1 wa, 0.0 hi, 0.5 si, 0.2 st MiB Mem : 5962.5 total, 2602.5 free, 2212.2 used, 1147.8 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 3472.7 avail Mem PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20 0 20.9g 99232 46632 S 0.0 1.6 0:03.85 io.backitup.0 20 0 1504560 21768 2980 S 0.0 0.4 0:02.55 containerd 20 0 1468580 32732 4816 S 0.0 0.5 0:02.05 dockerd 20 0 1200840 338080 43876 S 19.9 5.5 1:55.42 iobroker.js-con 20 0 1145932 318060 43904 S 2.6 5.2 0:50.45 io.javascript.0 20 0 1007220 153680 44948 S 0.7 2.5 0:21.56 io.admin.0 20 0 954216 86952 38624 S 0.7 1.4 0:13.44 io.mqtt.0 20 0 951908 89820 39704 S 0.0 1.5 0:11.79 io.alexa2.0 20 0 948748 82332 38936 S 0.0 1.3 0:03.64 io.hm-rega.0 20 0 948496 87524 38880 S 0.0 1.4 0:03.68 io.hue-extended 20 0 948428 84012 38768 S 0.0 1.4 0:03.79 io.tr-064.0 20 0 946544 79408 38944 S 1.3 1.3 0:04.33 io.enigma2.0 20 0 943632 76980 39840 S 0.0 1.3 0:04.73 io.bluelink.0 20 0 820924 90136 44560 S 0.0 1.5 0:02.73 io.telegram.1 20 0 820156 89392 44560 S 0.7 1.5 0:02.66 io.telegram.0 20 0 815116 78924 39612 S 0.3 1.3 0:05.23 io.info.0 20 0 811420 77508 39428 S 0.0 1.3 0:02.62 io.hm-rpc.0 20 0 760300 95876 39504 S 0.0 1.6 0:04.94 io.iot.0 20 0 751820 82864 38372 S 2.3 1.4 0:08.39 io.history.0 20 0 743324 71956 39396 S 0.0 1.2 0:02.48 io.hm-rpc.1 20 0 741764 71628 38996 S 0.0 1.2 0:01.69 io.fritzbox.0 20 0 705424 86316 44600 S 0.0 1.4 0:03.72 io.mihome-vacuu 20 0 701808 99300 38664 S 0.0 1.6 0:04.03 io.vis-2-beta.0 20 0 687236 82232 38568 S 0.0 1.3 0:02.41 io.nuki-extende 20 0 686816 82548 38340 S 4.3 1.4 0:04.20 io.sonoff.0 20 0 685612 81156 38492 S 0.0 1.3 0:03.91 io.web.0 20 0 684288 81192 38688 S 4.0 1.3 0:05.95 io.upnp.0 20 0 681348 75932 38436 S 0.0 1.2 0:04.82 io.simple-api.0 20 0 680840 75360 38728 S 0.0 1.2 0:02.21 io.harmony.0 20 0 678788 76176 39912 S 0.0 1.2 0:02.38 io.email.0 20 0 677508 72596 38320 S 0.0 1.2 0:01.74 io.discovery.0 20 0 677508 72808 38328 S 0.0 1.2 0:01.70 io.ping.0 20 0 677388 71440 38364 S 0.0 1.2 0:01.58 io.echarts.0Ich stoppe den iob und starte ihn erneut mit allen Adaptern. Das stoppen benötigt eine Minute. Nachdem alle Adapter wieder laufen, benötigt der Controller 1,3 GB, also etwas mehr wie beim einzelnen Starten. Die Adapter bleiben aber gestartet.
Den Server hatte ich vor allen Aktionen rebooted. D.h. den hohen Speicherbedarf hatte ich auch nach einem Reboot.
Verstehen tue ich das jedenfalls nicht.
@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
benötigt der Controller 1,3 GB
wo nimmst du deine Zahlen her?
@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
20 0 1200840 338080 43876 S 19.9 5.5 1:55.42 iobroker.js-con
5.5% von 6GB sind 330MB
allerdings sind schon wieder 2.2GB RAM in Gebrauch.
sortiere die Liste mal nach mem% so dass man die großen Speicherfresser in den ersten Zeilen hat.
kein Support per PN! - Fragen im Forum stellen -
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
benötigt der Controller 1,3 GB
wo nimmst du deine Zahlen her?
@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
20 0 1200840 338080 43876 S 19.9 5.5 1:55.42 iobroker.js-con
5.5% von 6GB sind 330MB
allerdings sind schon wieder 2.2GB RAM in Gebrauch.
sortiere die Liste mal nach mem% so dass man die großen Speicherfresser in den ersten Zeilen hat.
-
Er nimmt die Zahlen aus der virt Spalte. Uninteressant für das Problem.
-
Hallo.
ich habe heute festgestellt, dass einige Adapter (zunächst echarts, später history, dann weitere) nicht mehr korrekt oder gar nicht mehr liefen. Aufgrund eines aktuellen Topic über Probleme mit dem echarts Adapters und zu wenig RAM habe ich an dieser Stelle nachgeforscht. Ich habe 6 GB RAM 3,2 GB nutzt allein der js-controller, jeweils 1 GB Javascript und Admin. Das kommt mir doch recht hoch vor. Kann es sein, dass wirklich so viel RAM dafür benötigt wird oder habe ich die Ursache an anderer Stelle zu suchen. Was könnte die Ursache sein?
Versionen:
Adapter "javascript" : 7.0.3 , installed 7.0.3
Adapter "admin" : 6.8.0 , installed 6.8.0
Controller "js-controller": 4.0.24 , installed 4.0.24
Node.js v18.16.0@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
Was könnte die Ursache sein?
Moin,
nicht direkt eine Idee, aber um Dir besser zu helfen, solltest Du glaube ich, erst einmal beschreiben, worauf Dein
ioBrokerläuft und ob da noch mehr läuft oder nur derioBroker
Und dann das nachliefern, worum Dich @Thomas-Braun gebeten hat# iob diagVG
Bernd -
@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
Was könnte die Ursache sein?
Moin,
nicht direkt eine Idee, aber um Dir besser zu helfen, solltest Du glaube ich, erst einmal beschreiben, worauf Dein
ioBrokerläuft und ob da noch mehr läuft oder nur derioBroker
Und dann das nachliefern, worum Dich @Thomas-Braun gebeten hat# iob diagVG
Bernd@dp20eic sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
ob da noch mehr läuft
deshalb das sortierte
top
wenn da was RAM verbrät, sähe man es -
@homoran
Resident sind 2,3GBTasks: 167 total, 1 running, 166 sleeping, 0 stopped, 0 zombie %Cpu(s): 7.9 us, 1.0 sy, 0.0 ni, 90.5 id, 0.0 wa, 0.0 hi, 0.4 si, 0.2 st MiB Mem : 5962.5 total, 723.0 free, 4278.8 used, 960.7 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 1410.2 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 608 iobroker 20 0 3205316 2.3g 19156 S 18.1 38.7 10:18.75 iobroker.js-con 1204 iobroker 20 0 750256 75144 17396 S 7.7 1.2 1:39.73 io.history.0 2319 iobroker 20 0 699136 79280 20932 S 3.2 1.3 0:53.56 io.upnp.0 2912 iobroker 20 0 993876 320928 43728 S 2.8 5.3 2:14.41 io.javascript.0 1334 iobroker 20 0 700384 69540 16948 S 2.0 1.1 0:41.79 io.sonoff.0 16226 root 20 0 8484 3620 2888 R 0.8 0.1 0:00.04 top 1 root 20 0 169700 7468 4892 S 0.4 0.1 0:05.71 systemd 939 root 20 0 1468580 32732 4816 S 0.4 0.5 0:01.29 dockerd 1149 kress 20 0 15740 3528 1860 S 0.4 0.1 0:05.32 sshd 1250 iobroker 20 0 959676 76392 22072 S 0.4 1.3 0:12.97 io.telegram.1 1289 iobroker 20 0 706960 59156 16936 S 0.4 1.0 0:07.27 io.mihome-vacuu 1304 iobroker 20 0 960872 74328 16360 S 0.4 1.2 0:58.54 io.mqtt.0 2273 iobroker 20 0 950028 65372 22052 S 0.4 1.1 0:09.20 io.info.0@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
dockerd
ist ja auch schon ein Hinweis
-
@dp20eic sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
ob da noch mehr läuft
deshalb das sortierte
top
wenn da was RAM verbrät, sähe man es@homoran sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
deshalb das sortierte top
wenn da was RAM verbrät, sähe man esMoin,
klar, könnte man das, aber warum muss der Helfende suchen, wenn der Hilfesuchende doch gleich die benötigten Informationen liefer kann ;)
Ist halt oft so, dass die ersten X Posts, nur reine Informationsabfrage sind, bevor man an der Lösung arbeitet.@MarkusK
Das geht nicht persönlich gegen Dich oder andere hier im Forum.
Mir ist vollkommen klar, dass Du einfach nur nach Hilfe suchst.VG
Bernd -
@homoran sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
deshalb das sortierte top
wenn da was RAM verbrät, sähe man esMoin,
klar, könnte man das, aber warum muss der Helfende suchen, wenn der Hilfesuchende doch gleich die benötigten Informationen liefer kann ;)
Ist halt oft so, dass die ersten X Posts, nur reine Informationsabfrage sind, bevor man an der Lösung arbeitet.@MarkusK
Das geht nicht persönlich gegen Dich oder andere hier im Forum.
Mir ist vollkommen klar, dass Du einfach nur nach Hilfe suchst.VG
BerndHier die gewünschten Infos:
iobroker läuft auf debian in einer KVM mit 6GB zugewiesenen RAM. Die Hardware ist ein Intel NUC mit 8GB RAM und einen Debian als Wirt.
Aktuell verwendet der IOB 6,8% des RAM, aber weiterhin 11,2 GB, was mir doch sehr hoch vorkommt. Auch wenn ich alle Instanzen der Adapter stoppe (im TOP unten laufen sie jedoch) und den IOB neu starte, ändert sich nichts an der Größe des virt. RAM. Es bleibt die Frage offen, warum reserviert sich der js-controller so viel RAM und ist das normal?
Der js-controller hat jetzt die Version 5.0.12
Top sortiert nach %MEM:
top - 13:03:49 up 1 day, 3:54, 2 users, load average: 1.42, 1.20, 0.78 Tasks: 172 total, 1 running, 171 sleeping, 0 stopped, 0 zombie %Cpu(s): 3.4 us, 1.8 sy, 0.0 ni, 94.0 id, 0.0 wa, 0.0 hi, 0.2 si, 0.7 st MiB Mem : 5962.5 total, 1940.6 free, 2363.3 used, 1658.6 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 3266.1 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6473 iobroker 20 0 11.2g 417492 46232 S 6.6 6.8 2:49.30 iobroker.js-con 9808 iobroker 20 0 1003992 290596 44936 S 1.7 4.8 0:38.09 io.javascript.0 6497 iobroker 20 0 1053344 184920 45908 S 0.3 3.0 0:18.38 io.admin.0 11324 iobroker 20 0 20.9g 102656 47528 S 0.0 1.7 0:03.75 io.backitup.0 10052 iobroker 20 0 893364 97640 45256 S 0.3 1.6 0:04.98 io.telegram.0 10062 iobroker 20 0 893108 97048 45392 S 0.3 1.6 0:04.78 io.telegram.1 10425 iobroker 20 0 959684 96524 39324 S 2.0 1.6 0:08.46 io.tr-064.0 8789 iobroker 20 0 959852 96244 40324 S 0.7 1.6 0:13.64 io.alexa2.0 9772 iobroker 20 0 763108 95748 39884 S 0.3 1.6 0:04.44 io.iot.0 9341 iobroker 20 0 955656 94936 39248 S 0.3 1.6 0:08.34 io.hue-extended 10004 iobroker 20 0 692700 94512 38884 S 2.0 1.5 0:09.36 io.sonoff.0 9868 iobroker 20 0 958308 93812 39028 S 0.0 1.5 0:11.06 io.mqtt.0 10515 iobroker 20 0 697084 93520 39368 S 0.0 1.5 0:13.99 io.upnp.0MOD-EDIT: Code in code-tags gesetzt!
Hier noch die Ausgabe von free:
total used free shared buff/cache available Mem: 6105560 2450600 1945404 73552 1709556 3313776MOD-EDIT: Code in code-tags gesetzt!
-
Hier die gewünschten Infos:
iobroker läuft auf debian in einer KVM mit 6GB zugewiesenen RAM. Die Hardware ist ein Intel NUC mit 8GB RAM und einen Debian als Wirt.
Aktuell verwendet der IOB 6,8% des RAM, aber weiterhin 11,2 GB, was mir doch sehr hoch vorkommt. Auch wenn ich alle Instanzen der Adapter stoppe (im TOP unten laufen sie jedoch) und den IOB neu starte, ändert sich nichts an der Größe des virt. RAM. Es bleibt die Frage offen, warum reserviert sich der js-controller so viel RAM und ist das normal?
Der js-controller hat jetzt die Version 5.0.12
Top sortiert nach %MEM:
top - 13:03:49 up 1 day, 3:54, 2 users, load average: 1.42, 1.20, 0.78 Tasks: 172 total, 1 running, 171 sleeping, 0 stopped, 0 zombie %Cpu(s): 3.4 us, 1.8 sy, 0.0 ni, 94.0 id, 0.0 wa, 0.0 hi, 0.2 si, 0.7 st MiB Mem : 5962.5 total, 1940.6 free, 2363.3 used, 1658.6 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 3266.1 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6473 iobroker 20 0 11.2g 417492 46232 S 6.6 6.8 2:49.30 iobroker.js-con 9808 iobroker 20 0 1003992 290596 44936 S 1.7 4.8 0:38.09 io.javascript.0 6497 iobroker 20 0 1053344 184920 45908 S 0.3 3.0 0:18.38 io.admin.0 11324 iobroker 20 0 20.9g 102656 47528 S 0.0 1.7 0:03.75 io.backitup.0 10052 iobroker 20 0 893364 97640 45256 S 0.3 1.6 0:04.98 io.telegram.0 10062 iobroker 20 0 893108 97048 45392 S 0.3 1.6 0:04.78 io.telegram.1 10425 iobroker 20 0 959684 96524 39324 S 2.0 1.6 0:08.46 io.tr-064.0 8789 iobroker 20 0 959852 96244 40324 S 0.7 1.6 0:13.64 io.alexa2.0 9772 iobroker 20 0 763108 95748 39884 S 0.3 1.6 0:04.44 io.iot.0 9341 iobroker 20 0 955656 94936 39248 S 0.3 1.6 0:08.34 io.hue-extended 10004 iobroker 20 0 692700 94512 38884 S 2.0 1.5 0:09.36 io.sonoff.0 9868 iobroker 20 0 958308 93812 39028 S 0.0 1.5 0:11.06 io.mqtt.0 10515 iobroker 20 0 697084 93520 39368 S 0.0 1.5 0:13.99 io.upnp.0MOD-EDIT: Code in code-tags gesetzt!
Hier noch die Ausgabe von free:
total used free shared buff/cache available Mem: 6105560 2450600 1945404 73552 1709556 3313776MOD-EDIT: Code in code-tags gesetzt!
@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
warum reserviert sich der js-controller so viel RAM
nach dieser Info tut er das nicht.
@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
6473 iobroker 20 0 11.2g 417492 46232 S 6.6 6.8 2:49.30 iobroker.js-conWenn du trotzdem der Meinung bist, solltest dies mal beobachten.
Steigt der RAM-Verbrauch plötzlich an, musst du suchen was sich gerade geändert hat -
Hier die gewünschten Infos:
iobroker läuft auf debian in einer KVM mit 6GB zugewiesenen RAM. Die Hardware ist ein Intel NUC mit 8GB RAM und einen Debian als Wirt.
Aktuell verwendet der IOB 6,8% des RAM, aber weiterhin 11,2 GB, was mir doch sehr hoch vorkommt. Auch wenn ich alle Instanzen der Adapter stoppe (im TOP unten laufen sie jedoch) und den IOB neu starte, ändert sich nichts an der Größe des virt. RAM. Es bleibt die Frage offen, warum reserviert sich der js-controller so viel RAM und ist das normal?
Der js-controller hat jetzt die Version 5.0.12
Top sortiert nach %MEM:
top - 13:03:49 up 1 day, 3:54, 2 users, load average: 1.42, 1.20, 0.78 Tasks: 172 total, 1 running, 171 sleeping, 0 stopped, 0 zombie %Cpu(s): 3.4 us, 1.8 sy, 0.0 ni, 94.0 id, 0.0 wa, 0.0 hi, 0.2 si, 0.7 st MiB Mem : 5962.5 total, 1940.6 free, 2363.3 used, 1658.6 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 3266.1 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6473 iobroker 20 0 11.2g 417492 46232 S 6.6 6.8 2:49.30 iobroker.js-con 9808 iobroker 20 0 1003992 290596 44936 S 1.7 4.8 0:38.09 io.javascript.0 6497 iobroker 20 0 1053344 184920 45908 S 0.3 3.0 0:18.38 io.admin.0 11324 iobroker 20 0 20.9g 102656 47528 S 0.0 1.7 0:03.75 io.backitup.0 10052 iobroker 20 0 893364 97640 45256 S 0.3 1.6 0:04.98 io.telegram.0 10062 iobroker 20 0 893108 97048 45392 S 0.3 1.6 0:04.78 io.telegram.1 10425 iobroker 20 0 959684 96524 39324 S 2.0 1.6 0:08.46 io.tr-064.0 8789 iobroker 20 0 959852 96244 40324 S 0.7 1.6 0:13.64 io.alexa2.0 9772 iobroker 20 0 763108 95748 39884 S 0.3 1.6 0:04.44 io.iot.0 9341 iobroker 20 0 955656 94936 39248 S 0.3 1.6 0:08.34 io.hue-extended 10004 iobroker 20 0 692700 94512 38884 S 2.0 1.5 0:09.36 io.sonoff.0 9868 iobroker 20 0 958308 93812 39028 S 0.0 1.5 0:11.06 io.mqtt.0 10515 iobroker 20 0 697084 93520 39368 S 0.0 1.5 0:13.99 io.upnp.0MOD-EDIT: Code in code-tags gesetzt!
Hier noch die Ausgabe von free:
total used free shared buff/cache available Mem: 6105560 2450600 1945404 73552 1709556 3313776MOD-EDIT: Code in code-tags gesetzt!
@markusk sagte in Adapter beenden sich. Zu wenig RAM wg. js-controller?:
Aktuell verwendet der IOB 6,8% des RAM, aber weiterhin 11,2 GB,
Moin,
hier mal die Beschreibung, was die einzelnen Überschriften und Spalten bedeuten -> https://wiki.ubuntuusers.de/top/
Prozess-Zeile:Abkürzung Bedeutung PID Prozess-ID USER Benutzer, der den Prozess gestartet hat PR Prioritätsscheduling, z.B. rt für Real Time (irreführend, da der Linux-Kernel standardmäßig nicht in Echtzeit läuft) NI Nice VIRT virtual - alle Code-, Daten- und Shared Libraries plus Seiten im Swap und Seiten, die verplant aber noch nicht genutzt werden RES reserved - der nicht-ge"swap"te physikalische Arbeitsspeicher SHR shared - Speicher (auch Swap) der mit anderen Prozessen geteilt werden könnte S Status (D = ununterbrechbarer Schlaf, R = läuft, S = schläft, T = mit ´´trace´´ auf Fehlersuche oder gestoppt, Z = Zombie) %CPU Prozentzahl der abgelaufenen CPU-Zeit, die der Prozess verwendet hat %MEM Memory - verwendeter Teil des verfügbaren physikalischen Arbeitsspeichers TIME+ CPU-Zeit, die der Prozess benutzt hat (das + steht für hundertstel Sekunden) COMMAND Befehlsname oder -zeile Wenn ich das bei mir anschaue, dann kommen auch mal Adapter zum Vorschein, die
VIRT10g anzeigen, also%MEMist da schon der Wert, den man im Auge behlten sollte und nichtVIRT.top - 13:54:30 up 1 day, 23:05, 1 user, load average: 0.85, 0.86, 1.06 Tasks: 51 total, 2 running, 49 sleeping, 0 stopped, 0 zombie %Cpu(s): 8.0 us, 8.7 sy, 0.0 ni, 82.9 id, 0.3 wa, 0.0 hi, 0.1 si, 0.0 st MiB Mem : 67.9/3600.0 [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| ] MiB Swap: 0.0/2048.0 [ ] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 179 iobroker 20 0 1375420 472016 11136 R 7.0 12.8 251:25.00 iobroker.js-con 1596 iobroker 20 0 10.9g 87784 11648 S 3.3 2.4 60:39.81 io.fb-checkpres <- 1228 iobroker 20 0 993116 102712 13312 S 2.0 2.8 59:20.76 io.zwave2.0 507 iobroker 20 0 972608 93748 9984 S 1.7 2.5 42:10.54 io.influxdb.2 631 iobroker 20 0 806600 110836 10752 S 1.7 3.0 24:21.72 io.zigbee.0 1136 iobroker 20 0 685236 83392 10752 S 1.0 2.3 7:19.32 io.sonoff.0 182 promtail 20 0 1875208 28032 9088 S 0.7 0.8 18:31.23 promtail 112 avahi 20 0 7460 1536 1152 S 0.3 0.0 0:20.72 avahi-daemon 1692 iobroker 20 0 691544 90968 8832 S 0.3 2.5 3:45.63 io.iqontrol.0 34192 dp20eic 20 0 7132 2304 1792 R 0.3 0.1 0:00.05 top 1 root 20 0 165604 4992 2816 S 0.0 0.1 0:01.37 systemd 49 root 20 0 64772 9344 8576 S 0.0 0.3 0:00.46 systemd-journal 83 systemd+ 20 0 16216 2432 1664 S 0.0 0.1 0:05.27 systemd-network 101 root 20 0 99880 2268 1024 S 0.0 0.1 0:00.01 dhclient 106 _rpc 20 0 7900 640 256 S 0.0 0.0 0:00.13 rpcbind 113 message+ 20 0 8356 1664 1280 S 0.0 0.0 0:00.11 dbus-daemon 115 root 20 0 151184 1664 1024 S 0.0 0.0 0:00.09 rsyslogd 116 root 20 0 13848 3200 2560 S 0.0 0.1 0:00.25 systemd-logind 118 avahi 20 0 7148 392 128 S 0.0 0.0 0:00.00 avahi-daemon 192 root 20 0 13352 1664 768 S 0.0 0.0 0:00.01 sshd 208 statd 20 0 4720 556 256 S 0.0 0.0 0:00.00 rpc.statd 215 root 20 0 3912 512 384 S 0.0 0.0 0:00.27 cron 221 root 20 0 2504 128 128 S 0.0 0.0 0:00.00 agetty 222 root 20 0 2504 128 128 S 0.0 0.0 0:00.00 agetty 224 root 20 0 2504 128 128 S 0.0 0.0 0:00.00 agetty 387 root 20 0 40052 796 384 S 0.0 0.0 0:00.54 master 389 postfix 20 0 40528 1024 384 S 0.0 0.0 0:00.18 qmgr 406 iobroker 20 0 1076944 155556 9856 S 0.0 4.2 4:11.53 io.admin.0 449 iobroker 20 0 786696 178768 10624 S 0.0 4.8 27:30.85 io.javascript.0 602 iobroker 20 0 979148 88068 12416 S 0.0 2.4 4:51.71 io.meross.0 1013 iobroker 20 0 10.9g 81420 12416 S 0.0 2.2 4:51.17 io.wolf-smartse <- 1075 iobroker 20 0 664664 59844 8832 S 0.0 1.6 4:02.91 io.nut.0 1102 iobroker 20 0 968100 78128 11392 S 0.0 2.1 5:07.62 io.radar2.0 1161 iobroker 20 0 666768 64804 8832 S 0.0 1.8 3:46.17 io.web.0 1212 iobroker 20 0 687620 79636 8832 S 0.0 2.2 3:50.06 io.simple-api.0 1262 iobroker 20 0 665416 66908 9088 S 0.0 1.8 3:49.91 io.trashschedul 1375 iobroker 20 0 10.9g 68184 10752 S 0.0 1.8 3:50.48 io.withings.0 <- 1457 iobroker 20 0 10.9g 56672 11648 S 0.0 1.5 3:42.52 io.synochat.0 1516 iobroker 20 0 658912 54316 8832 S 0.0 1.5 3:42.12 io.ws.0 1553 iobroker 20 0 958944 60428 12288 S 0.0 1.6 3:52.01 io.cloud.0 1630 iobroker 20 0 959684 152732 11648 S 0.0 4.1 4:39.86 io.tankerkoenig 1916 iobroker 20 0 659080 94836 10752 S 0.0 2.6 29:57.03 io.device-watch 2355 iobroker 20 0 971084 82472 12544 S 0.0 2.2 3:51.89 io.iot.0 2449 iobroker 20 0 10.9g 82784 12416 S 0.0 2.2 5:50.51 io.hoover.0 2599 iobroker 20 0 968796 71908 12160 S 0.0 2.0 4:02.73 io.nuki-extende 33948 postfix 20 0 40472 4224 3584 S 0.0 0.1 0:00.01 pickup 34156 root 20 0 14708 5760 4608 S 0.0 0.2 0:00.01 sshd 34159 dp20eic 20 0 15260 6528 5248 S 0.0 0.2 0:00.03 systemd 34160 dp20eic 20 0 168560 3924 1280 S 0.0 0.1 0:00.00 (sd-pam) 34178 dp20eic 20 0 14708 4308 3072 S 0.0 0.1 0:00.01 sshd 34179 dp20eic 20 0 5300 3584 2048 S 0.0 0.1 0:00.02 bashVG
Bernd
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 Anmelden215
Online32.8k
Benutzer82.9k
Themen1.3m
Beiträge