Load average am Anschlag -> Neustart
-
@Homoran sagte:
für js.1 im chart integriertBei Input von 4000 muss ein Adapter schnell viele DP aktualisieren.
-
Im text schreibst du der 2. chart zeigt die cpu last ich gehe davon aus
Tat ich das?
sorry.
Cpu last ist ganz unten die Tabelle!du sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?
09:04, siehe Tabelle
Der chart zeigt leider durch die Aggregation nicht immer alle kurzen aber massiven Ausschläge an 😞
nur eine vermutung und evtl hinweise fürs weitersuchen.
Danke, das ist genau was ich brauche!
Aber Skripte sehe ich nicht, der js-Adapter läuft ruhig.
bei 9:00 stärker (leider abgeschnitten)
Müsste ich mal versuchen den "echten" Wert herauszufinden
DANKE
Edit:
Homoran sagte:
@OliverIO sagte:
du sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?
09:04, siehe Tabelle
@oliverio
Ich hab da noch was gefunden2026-08-23 08:58:42.519 - info: admin.0 (1197) Adapter rating updated
Das kommt mir aber bekannt vor.
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 - -
Ich hab da noch was gefunden
2026-08-23 08:58:42.519 - info: admin.0 (1197) Adapter rating updated
Das kommt mir aber bekannt vor.
der admin hat die ratings, also die bewertungssterne der adapter gelesen
https://github.com/ioBroker/ioBroker.socket-classes/blob/aea61897afee4642784737c162760db9bcdcf4fe/src/lib/socketCommandsAdmin.ts#L267 -
Ich hab da noch was gefunden
2026-08-23 08:58:42.519 - info: admin.0 (1197) Adapter rating updated
Das kommt mir aber bekannt vor.
der admin hat die ratings, also die bewertungssterne der adapter gelesen
https://github.com/ioBroker/ioBroker.socket-classes/blob/aea61897afee4642784737c162760db9bcdcf4fe/src/lib/socketCommandsAdmin.ts#L267@OliverIO danke, ja das weiss ich.
Aber ich habe einige Absturzberichte im Hinterkopf, bei denen auch das lesen der ratings das letzte Lebenszeichen war. Die finde ich gerade nicht mehr.Ist aber wahrscheinlich nur Zufall, gestern 14:10 war da nichts entsprechendes im log.
Hier
Habe ich mal sie counts auf max aggregiert.
Input kommt auf gut 3000, output auf 600Das korreliert nicht (??) mit den peaks bei load.
Auch wenn es bei 15:30 so sein könnte, habe ich dort mit dem Zoom in einem flot chart gespielt, bis die load auf 4 war. Danach aufgehört und die load fing sich wieder.
Das käme meiner Theorie vom Zugriff auf die SD und hoher I/O entgegen.
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 - -
@OliverIO danke, ja das weiss ich.
Aber ich habe einige Absturzberichte im Hinterkopf, bei denen auch das lesen der ratings das letzte Lebenszeichen war. Die finde ich gerade nicht mehr.Ist aber wahrscheinlich nur Zufall, gestern 14:10 war da nichts entsprechendes im log.
Hier
Habe ich mal sie counts auf max aggregiert.
Input kommt auf gut 3000, output auf 600Das korreliert nicht (??) mit den peaks bei load.
Auch wenn es bei 15:30 so sein könnte, habe ich dort mit dem Zoom in einem flot chart gespielt, bis die load auf 4 war. Danach aufgehört und die load fing sich wieder.
Das käme meiner Theorie vom Zugriff auf die SD und hoher I/O entgegen.
wenn ich mich recht erinnere setzt du das standard jsonl als datenbank format ein. wenn du viele datenpunkte hast und auch viel history machst, kommst du evtl an die grenzen?
evtl mal redis probieren? -
wenn ich mich recht erinnere setzt du das standard jsonl als datenbank format ein. wenn du viele datenpunkte hast und auch viel history machst, kommst du evtl an die grenzen?
evtl mal redis probieren?@OliverIO Danke!
Wäre vielleicht mal zu testen, ist für mich aber eher eine Symptombekämpfung.Wenn es nicht eine kritische Masse gibt, nach deren Überschreitung alles zusammenbricht ergibt das für mich keinen Sinn.
Ich logge diese Daten seit 12 Jahren auf allen bisherigen Systemen.
Seit Umzug auf den Pi5 lag die load durchgehend unter 1 (backup und install ausgenommen)Seit 2-3 Wochen jetzt diese immensen Ausreißer.
Ich weiss dass ich mit history übertrieben habe, aber ich habe gestern 30GB! Daten aus 2021 und 2022 gelöscht.
Wenn getHistory überlastet war, hätte das IMHO schleichend beginnen und nach der Radikalkur wieder beendet sein müssen.Skripte habe ich nocht in den letzten Wochen neu angelegt oder geändert.
Es kann aus meiner Logik eher ein Adapter- oder nodejs Update verursacht haben.
-
Update:
Gestern abend stieg noch einmal die Load an den Anschlag, warum auch immer.
Anscheinend regelte das System dagegen an, indem die CPU Frequenz auf 2400 ging bis die load etwa unter 2 fiel, danach stieg die Load wieder usw.Hier aggregiert auf minmax
Um die Spitzen besser zu sehen, load, js.0 in und out jetzt aggregiert auf max
Ich sehe da keine Korrelation von load zu js.
Der memfree fiel schon 1h vorher leicht ab und ging nach dem Backup um 03:30 erst wieder zurück zum alten Wert
-
Nach gut 48h ist es wieder passiertIch hatte virher noch Daten gesammelt, und auch input und output counts vom History geloggt.
Auch da keine wirkliche Korrelation zu immer häufiger werdenden höheren load Werten gesehen.Dann stiegen die load maxima wieder über 10 bis 25. (Vorher eigentlich immer nur knapp über 4),
Top zeigte nichts verwertbares an
Lediglich der mögliche Hinweis auf historydann musste ich aus dem Haus.
Als ich wiederkam ist die uptime nur noch 0.1 Tag
15:41 ist iobroker wieder hochgefahren!Ich hab immer noch keinerlei blassen Schimmer was da los ist.
EDIT:
Hab seitenweise EPIPE, ECONNRESET 9000 und 9001 im log!Ist das etwa dasselbe hier?
https://forum.iobroker.net/topic/85231/unregelmäßig-unmotivierter-neustart-aller-instanzen/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 - -
Kann man die verdächtigen Module ggfs. einfach mal für einen Test disablen. Scheint ja erstmal nichts zu betreffen, was die Steuerung der Heimautomatisierung angeht...
Intel(R) Celeron(R) CPU N3000 @1.04GHz 8G RAM 480G SSD * Virtualization : unprivileged lxc container on Proxmox * 6 GByte RAM für den iobroker Container * Remote-Access über Wireguard meiner Fritzbox
-
Nach gut 48h ist es wieder passiertIch hatte virher noch Daten gesammelt, und auch input und output counts vom History geloggt.
Auch da keine wirkliche Korrelation zu immer häufiger werdenden höheren load Werten gesehen.Dann stiegen die load maxima wieder über 10 bis 25. (Vorher eigentlich immer nur knapp über 4),
Top zeigte nichts verwertbares an
Lediglich der mögliche Hinweis auf historydann musste ich aus dem Haus.
Als ich wiederkam ist die uptime nur noch 0.1 Tag
15:41 ist iobroker wieder hochgefahren!Ich hab immer noch keinerlei blassen Schimmer was da los ist.
EDIT:
Hab seitenweise EPIPE, ECONNRESET 9000 und 9001 im log!Ist das etwa dasselbe hier?
https://forum.iobroker.net/topic/85231/unregelmäßig-unmotivierter-neustart-aller-instanzen/Steht was in
dmesg -Tzu den Zeiten drin?
Alternativ schau mal perjournalctlwas da so geloggt wird. Details hier:
Linux-Werkzeugkasten:
https://forum.iobroker.net/topic/42952/der-kleine-iobroker-linux-werkzeugkasten
NodeJS Fixer Skript:
https://forum.iobroker.net/topic/68035/iob-node-fix-skript
iob_diag: curl -sLf -o diag.sh https://iobroker.net/diag.sh && bash diag.sh -
Kann man die verdächtigen Module ggfs. einfach mal für einen Test disablen. Scheint ja erstmal nichts zu betreffen, was die Steuerung der Heimautomatisierung angeht...
-
Steht was in
dmesg -Tzu den Zeiten drin?
Alternativ schau mal perjournalctlwas da so geloggt wird. Details hier:
dmesg -T
Das was ich gesucht hatte ist drin:
[Thu Aug 27 15:40:15 2026] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=iobroker.js-con,pid=533421,uid=1001 [Thu Aug 27 15:40:15 2026] Out of memory: Killed process 533421 (iobroker.js-con) total-vm:12096752kB, anon-rss:150480kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:28000kB oom_score_adj:0 [Thu Aug 27 15:40:17 2026] oom_reaper: reaped process 533421 (iobroker.js-con), now anon-rss:768kB, file-rss:0kB, shmem-rss:0kB puh@BrokerRaspi:~ $journalctl
Alles?
lines 5575-5627/5656 100%
Oder nur das rote
Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:18 GOTO="alsa_restore_std" has no matching label, ignoring. Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:18 The line has no effect any more, dropping. Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:22 GOTO="alsa_restore_std" has no matching label, ignoring. Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:22 The line has no effect any more, dropping. . . . Aug 25 14:14:07 BrokerRaspi systemd[1]: Reached target remote-fs-pre.target - Preparation for Remote File Systems. Aug 25 14:14:07 BrokerRaspi systemd[1]: Reached target remote-fs.target - Remote File Systems. Aug 25 14:14:07 BrokerRaspi blkmapd[766]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory Aug 25 14:14:07 BrokerRaspi systemd[1]: Started nfs-blkmap.service - pNFS block layout mapping daemon. . . . Aug 27 15:27:33 BrokerRaspi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=iobroker.js-con,pid=1191,uid=1001 Aug 27 15:27:33 BrokerRaspi kernel: Out of memory: Killed process 1191 (iobroker.js-con) total-vm:12474624kB, anon-rss:335120kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:32976kB oom_score_adj:0 Aug 27 15:28:34 BrokerRaspi kernel: cron invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0 . . . Aug 27 15:28:36 BrokerRaspi kernel: [ 531576] 1001 531576 6381 6 0 6 0 98304 0 0 node Aug 27 15:28:36 BrokerRaspi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=io.javascript.1,pid=1474,uid=1001 Aug 27 15:28:36 BrokerRaspi kernel: Out of memory: Killed process 1474 (io.javascript.1) total-vm:12129424kB, anon-rss:205536kB, file-rss:256kB, shmem-rss:0kB, UID:1001 pgtables:22080kB oom_score_adj:0 Aug 27 15:28:36 BrokerRaspi systemd[1]: iobroker.service: Main process exited, code=killed, status=9/KILL . . . . Aug 27 15:40:16 BrokerRaspi kernel: [ 538774] 1001 538774 6712 12 0 12 0 98304 0 0 node Aug 27 15:40:16 BrokerRaspi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=iobroker.js-con,pid=533421,uid=1001 Aug 27 15:40:16 BrokerRaspi kernel: Out of memory: Killed process 533421 (iobroker.js-con) total-vm:12096752kB, anon-rss:150480kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:28000kB oom_score_adj:0 Aug 27 15:40:16 BrokerRaspi kernel: oom_reaper: reaped process 533421 (iobroker.js-con), now anon-rss:768kB, file-rss:0kB, shmem-rss:0kB . . .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 - -
dmesg -T
Das was ich gesucht hatte ist drin:
[Thu Aug 27 15:40:15 2026] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=iobroker.js-con,pid=533421,uid=1001 [Thu Aug 27 15:40:15 2026] Out of memory: Killed process 533421 (iobroker.js-con) total-vm:12096752kB, anon-rss:150480kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:28000kB oom_score_adj:0 [Thu Aug 27 15:40:17 2026] oom_reaper: reaped process 533421 (iobroker.js-con), now anon-rss:768kB, file-rss:0kB, shmem-rss:0kB puh@BrokerRaspi:~ $journalctl
Alles?
lines 5575-5627/5656 100%
Oder nur das rote
Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:18 GOTO="alsa_restore_std" has no matching label, ignoring. Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:18 The line has no effect any more, dropping. Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:22 GOTO="alsa_restore_std" has no matching label, ignoring. Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:22 The line has no effect any more, dropping. . . . Aug 25 14:14:07 BrokerRaspi systemd[1]: Reached target remote-fs-pre.target - Preparation for Remote File Systems. Aug 25 14:14:07 BrokerRaspi systemd[1]: Reached target remote-fs.target - Remote File Systems. Aug 25 14:14:07 BrokerRaspi blkmapd[766]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory Aug 25 14:14:07 BrokerRaspi systemd[1]: Started nfs-blkmap.service - pNFS block layout mapping daemon. . . . Aug 27 15:27:33 BrokerRaspi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=iobroker.js-con,pid=1191,uid=1001 Aug 27 15:27:33 BrokerRaspi kernel: Out of memory: Killed process 1191 (iobroker.js-con) total-vm:12474624kB, anon-rss:335120kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:32976kB oom_score_adj:0 Aug 27 15:28:34 BrokerRaspi kernel: cron invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0 . . . Aug 27 15:28:36 BrokerRaspi kernel: [ 531576] 1001 531576 6381 6 0 6 0 98304 0 0 node Aug 27 15:28:36 BrokerRaspi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=io.javascript.1,pid=1474,uid=1001 Aug 27 15:28:36 BrokerRaspi kernel: Out of memory: Killed process 1474 (io.javascript.1) total-vm:12129424kB, anon-rss:205536kB, file-rss:256kB, shmem-rss:0kB, UID:1001 pgtables:22080kB oom_score_adj:0 Aug 27 15:28:36 BrokerRaspi systemd[1]: iobroker.service: Main process exited, code=killed, status=9/KILL . . . . Aug 27 15:40:16 BrokerRaspi kernel: [ 538774] 1001 538774 6712 12 0 12 0 98304 0 0 node Aug 27 15:40:16 BrokerRaspi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=iobroker.js-con,pid=533421,uid=1001 Aug 27 15:40:16 BrokerRaspi kernel: Out of memory: Killed process 533421 (iobroker.js-con) total-vm:12096752kB, anon-rss:150480kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:28000kB oom_score_adj:0 Aug 27 15:40:16 BrokerRaspi kernel: oom_reaper: reaped process 533421 (iobroker.js-con), now anon-rss:768kB, file-rss:0kB, shmem-rss:0kB . . .Alles?
Man kann das ganz wunderbar auf bestimmte Betrachtungszeiträume beschränken. Steht alles im Schnubbibuntu-Wiki drin, aus dem Kopf weiß ich die genaue Syntax auch nicht.
Linux-Werkzeugkasten:
https://forum.iobroker.net/topic/42952/der-kleine-iobroker-linux-werkzeugkasten
NodeJS Fixer Skript:
https://forum.iobroker.net/topic/68035/iob-node-fix-skript
iob_diag: curl -sLf -o diag.sh https://iobroker.net/diag.sh && bash diag.sh -
@Thomas-Braun Danke.
Such ich mir gerne nachher rausDie roten zeilen hab ich alle gezeigt
Dass es schlussendlich out of memory war, hab ich ja aus den charts vermutet, aber warum?
Hilft das letzte aus dem output
Aug 27 18:01:37 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] Aug 27 18:02:41 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] Aug 27 18:03:51 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] Aug 27 18:04:28 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] Aug 27 18:04:46 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] Aug 27 18:05:11 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging]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 - -
Wer Speicher frisst, kann man sich auch anzeigen lassen...
Die Prozesse, sortiert von oben nach unten nach dem Speicherverbrauch.
Kann aber langweilig werden, wenn man davor sitzen muss ...
Wenn es Vorzeichen gibt, kann man sich ja über iobroker alarmieren lassen, wenn es spannend wird ...Linux Console
top -o %MEM- echtzeit-Anzeige
top -o %MEM -n 1- ein Durchlauf, kann man auch in Datei umleiten lassen (ggfs mit linux-control sogar von iobroker starten lassen)top - 18:36:03 up 1 day, 2:03, 0 users, load average: 3.43, 3.57, 3.73 Tasks: 66 total, 1 running, 65 sleeping, 0 stopped, 0 zombie %Cpu(s): 27.5 us, 25.5 sy, 0.0 ni, 43.8 id, 0.5 wa, 0.0 hi, 2.7 si, 0.0 st MiB Mem : 6144.0 total, 2979.2 free, 2562.4 used, 602.5 buff/cache MiB Swap: 6144.0 total, 4956.9 free, 1187.1 used. 3581.6 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 410 iobroker 20 0 12.1g 247056 29684 S 9.4 3.9 205:08.33 iobroker.js-con 354 grafana 20 0 2147780 216260 81568 S 2.6 3.4 36:43.40 grafana 106 influxdb 20 0 4706888 192716 31064 S 4.9 3.1 198:46.98 influxd 498 iobroker 20 0 22.0g 189992 42472 S 0.0 3.0 2:23.22 io.admin.0 522 iobroker 20 0 12.0g 181988 39140 S 2.9 2.9 96:19.18 io.influxdb.0 554 iobroker 20 0 12.0g 181164 41612 S 2.3 2.9 62:00.97 io.javascript.0 570 iobroker 20 0 11.8g 145544 39192 S 2.3 2.3 44:19.36 io.javascript.1 601 iobroker 20 0 11.8g 124428 42428 S 0.3 2.0 9:39.54 io.mqtt.0 590 iobroker 20 0 11.7g 121228 40660 S 0.0 1.9 1:43.94 io.mqtt-client. 571 iobroker 20 0 11.9g 117876 41844 S 0.0 1.9 6:32.65 io.backitup.0 639 iobroker 20 0 11.7g 117788 41660 S 2.9 1.9 61:25.18 io.sonoff.0 816 iobroker 20 0 11.7g 116152 41380 S 0.3 1.8 2:15.27 io.simple-api.0 670 iobroker 20 0 11.9g 115492 42396 S 0.0 1.8 8:11.39 io.tr-064.0 51 root 20 0 233784 115160 114676 S 0.0 1.8 0:20.48 systemd-journal 646 iobroker 20 0 11.9g 113644 42556 S 0.0 1.8 4:27.48 io.meross.0 837 iobroker 20 0 21.7g 105520 41872 S 0.0 1.7 2:36.18 io.linux-contro 723 iobroker 20 0 11.9g 103152 42328 S 0.0 1.6 2:31.00 io.hm-rpc.0 801 iobroker 20 0 11.8g 103052 42320 S 0.0 1.6 1:44.38 io.web.0 773 iobroker 20 0 11.7g 99972 42172 S 0.0 1.6 2:40.04 io.hm-rega.0 534 iobroker 20 0 11.7g 97704 41924 S 0.0 1.6 1:39.59 io.email.0 659 iobroker 20 0 11.7g 97036 41252 S 0.0 1.5 1:52.47 io.snmp.0 795 iobroker 20 0 11.8g 96892 42248 S 0.0 1.5 1:32.61 io.vis-2.0 722 iobroker 20 0 11.7g 96848 41132 S 0.0 1.5 1:30.10 io.discovery.0Intel(R) Celeron(R) CPU N3000 @1.04GHz 8G RAM 480G SSD * Virtualization : unprivileged lxc container on Proxmox * 6 GByte RAM für den iobroker Container * Remote-Access über Wireguard meiner Fritzbox
-
Nachtrag Bei meiner "top" - Version gibt es noch einem Parameter, den aber nicht alle bieten
top -o %MEM -n 1 --scale-task-mem=mDamit wird der Speicherbedarf in Megabyte ausgegeben...
Tasks: 66 total, 1 running, 65 sleeping, 0 stopped, 0 zombie %Cpu(s): 17.4 us, 21.7 sy, 0.0 ni, 60.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 6144.0 total, 2991.9 free, 2563.1 used, 589.1 buff/cache MiB Swap: 6144.0 total, 4956.9 free, 1187.1 used. 3580.9 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 410 iobroker 20 0 12.1g 275.0m 29.0m S 0.0 4.5 206:46.87 iobroker.js-con 354 grafana 20 0 2097.7m 211.4m 79.7m S 0.0 3.4 37:01.41 grafana 498 iobroker 20 0 22.0g 185.5m 41.5m S 0.0 3.0 2:23.85 io.admin.0 106 influxdb 20 0 4596.6m 178.2m 30.3m S 0.0 2.9 200:17.88 influxd 522 iobroker 20 0 12.0g 171.6m 38.2m S 0.0 2.8 97:05.90 io.influxdb.0 554 iobroker 20 0 12.0g 160.4m 40.6m S 0.0 2.6 62:31.28 io.javascript.0 570 iobroker 20 0 11.8g 142.1m 38.3m S 0.0 2.3 44:40.54 io.javascript.1 601 iobroker 20 0 11.8g 121.5m 41.4m S 0.0 2.0 9:44.16 io.mqtt.0 590 iobroker 20 0 11.7g 118.5m 39.7m S 0.0 1.9 1:44.71 io.mqtt-client. 571 iobroker 20 0 11.9g 115.1m 40.9m S 0.0 1.9 6:33.21 io.backitup.0 639 iobroker 20 0 11.7g 114.4m 40.7m S 0.0 1.9 61:56.16 io.sonoff.0 816 iobroker 20 0 11.7g 113.4m 40.4m S 0.0 1.8 2:16.30 io.simple-api.0 51 root 20 0 228.3m 112.9m 112.4m S 0.0 1.8 0:20.61 systemd-journal 670 iobroker 20 0 11.9g 112.8m 41.4m S 0.0 1.8 8:14.95 io.tr-064.0 646 iobroker 20 0 11.9g 110.9m 41.6m S 8.3 1.8 4:29.42 io.meross.0 837 iobroker 20 0 21.7g 103.4m 40.9m S 0.0 1.7 2:37.33 io.linux-contro 723 iobroker 20 0 11.9g 100.8m 41.3m S 0.0 1.6 2:32.01 io.hm-rpc.0 801 iobroker 20 0 11.8g 100.6m 41.3m S 0.0 1.6 1:45.00 io.web.0 773 iobroker 20 0 11.7g 98.4m 41.2m S 0.0 1.6 2:41.13 io.hm-rega.0 659 iobroker 20 0 11.7g 94.8m 40.3m S 0.0 1.5 1:53.36 io.snmp.0 795 iobroker 20 0 11.8g 94.6m 41.3m S 0.0 1.5 1:33.15 io.vis-2.0 722 iobroker 20 0 11.7g 94.6m 40.2m S 0.0 1.5 1:30.81 io.discovery.0 534 iobroker 20 0 11.7g 93.6m 40.9m S 0.0 1.5 1:40.26 io.email.0 772 iobroker 20 0 11.7g 92.7m 40.3m S 0.0 1.5 3:50.66 io.ping.0 808 iobroker 20 0 11.1g 80.9m 33.4m S 0.0 1.3 13:48.18 io.reolink.0 710 iobroker 20 0 11.1g 80.3m 32.7m S 0.0 1.3 11:14.24 io.ems-esp.0 830 iobroker 20 0 11.1g 78.8m 33.4m S 0.0 1.3 13:31.45 io.reolink.1 822 iobroker 20 0 11.2g 77.5m 33.2m S 0.0 1.3 18:38.57 io.fb-checkpres 737 iobroker 20 0 11.1g 76.8m 33.1m S 0.0 1.3 2:45.78 io.fritzdect.0 793 iobroker 20 0 11.1g 74.6m 32.7m S 0.0 1.2 2:06.69 io.tradfri.0 716 iobroker 20 0 11.1g 74.2m 32.9m S 0.0 1.2 8:15.38 io.zigbee2mqtt. 640 iobroker 20 0 11.1g 73.3m 32.5m S 0.0 1.2 5:48.54 io.operating-ho 438 grafana 20 0 1259.6m 21.1m 14.9m S 0.0 0.3 0:05.54 gpx_grafana_inf 458 grafana 20 0 1269.8m 13.9m 8.3m S 0.0 0.2 0:05.69 gpx_grafana-lok 391 grafana 20 0 1265.2m 13.1m 8.5m S 0.0 0.2 0:04.94 gpx_grafana_ela 1 root 20 0 23.0m 11.5m 9.2m S 0.0 0.2 1:17.94 systemd 403 grafana 20 0 1254.5m 11.2m 10.0m S 0.0 0.2 0:00.37 gpx_dash_linux_ 101 root 20 0 18.7m 7.6m 6.9m S 0.0 0.1 0:12.04 systemd-logind 35315 postfix 20 0 43.5m 7.3m 6.6m S 0.0 0.1 0:00.02 pickup 329 postfix 20 0 43.5m 6.2m 6.1m S 0.0 0.1 0:00.16 qmgr martin@iobroker-test-sicher:~$ top -o %MEM -n 1 --scale-task-mem=m -
@Thomas-Braun Danke.
Such ich mir gerne nachher rausDie roten zeilen hab ich alle gezeigt
Dass es schlussendlich out of memory war, hab ich ja aus den charts vermutet, aber warum?
Hilft das letzte aus dem output
Aug 27 18:01:37 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] Aug 27 18:02:41 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] Aug 27 18:03:51 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] Aug 27 18:04:28 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] Aug 27 18:04:46 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] Aug 27 18:05:11 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] -
Wer Speicher frisst, kann man sich auch anzeigen lassen...
Die Prozesse, sortiert von oben nach unten nach dem Speicherverbrauch.
Kann aber langweilig werden, wenn man davor sitzen muss ...
Wenn es Vorzeichen gibt, kann man sich ja über iobroker alarmieren lassen, wenn es spannend wird ...Linux Console
top -o %MEM- echtzeit-Anzeige
top -o %MEM -n 1- ein Durchlauf, kann man auch in Datei umleiten lassen (ggfs mit linux-control sogar von iobroker starten lassen)top - 18:36:03 up 1 day, 2:03, 0 users, load average: 3.43, 3.57, 3.73 Tasks: 66 total, 1 running, 65 sleeping, 0 stopped, 0 zombie %Cpu(s): 27.5 us, 25.5 sy, 0.0 ni, 43.8 id, 0.5 wa, 0.0 hi, 2.7 si, 0.0 st MiB Mem : 6144.0 total, 2979.2 free, 2562.4 used, 602.5 buff/cache MiB Swap: 6144.0 total, 4956.9 free, 1187.1 used. 3581.6 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 410 iobroker 20 0 12.1g 247056 29684 S 9.4 3.9 205:08.33 iobroker.js-con 354 grafana 20 0 2147780 216260 81568 S 2.6 3.4 36:43.40 grafana 106 influxdb 20 0 4706888 192716 31064 S 4.9 3.1 198:46.98 influxd 498 iobroker 20 0 22.0g 189992 42472 S 0.0 3.0 2:23.22 io.admin.0 522 iobroker 20 0 12.0g 181988 39140 S 2.9 2.9 96:19.18 io.influxdb.0 554 iobroker 20 0 12.0g 181164 41612 S 2.3 2.9 62:00.97 io.javascript.0 570 iobroker 20 0 11.8g 145544 39192 S 2.3 2.3 44:19.36 io.javascript.1 601 iobroker 20 0 11.8g 124428 42428 S 0.3 2.0 9:39.54 io.mqtt.0 590 iobroker 20 0 11.7g 121228 40660 S 0.0 1.9 1:43.94 io.mqtt-client. 571 iobroker 20 0 11.9g 117876 41844 S 0.0 1.9 6:32.65 io.backitup.0 639 iobroker 20 0 11.7g 117788 41660 S 2.9 1.9 61:25.18 io.sonoff.0 816 iobroker 20 0 11.7g 116152 41380 S 0.3 1.8 2:15.27 io.simple-api.0 670 iobroker 20 0 11.9g 115492 42396 S 0.0 1.8 8:11.39 io.tr-064.0 51 root 20 0 233784 115160 114676 S 0.0 1.8 0:20.48 systemd-journal 646 iobroker 20 0 11.9g 113644 42556 S 0.0 1.8 4:27.48 io.meross.0 837 iobroker 20 0 21.7g 105520 41872 S 0.0 1.7 2:36.18 io.linux-contro 723 iobroker 20 0 11.9g 103152 42328 S 0.0 1.6 2:31.00 io.hm-rpc.0 801 iobroker 20 0 11.8g 103052 42320 S 0.0 1.6 1:44.38 io.web.0 773 iobroker 20 0 11.7g 99972 42172 S 0.0 1.6 2:40.04 io.hm-rega.0 534 iobroker 20 0 11.7g 97704 41924 S 0.0 1.6 1:39.59 io.email.0 659 iobroker 20 0 11.7g 97036 41252 S 0.0 1.5 1:52.47 io.snmp.0 795 iobroker 20 0 11.8g 96892 42248 S 0.0 1.5 1:32.61 io.vis-2.0 722 iobroker 20 0 11.7g 96848 41132 S 0.0 1.5 1:30.10 io.discovery.0 -
Leider ist der Controller heute nacht kurz nach Mitternacht wieder abgeschossen worden. (Sourceanalytix??)
Daraufhin hab ich heute morgen einiges probiert.Was mir dabei aufgefallen ist:
-
Seit dem vorigen kill reagierte der scaling governor deutlich langsamer
Die CPU-Frequenz lieb deutlich länger auf 2400MHz, was ich erst als gutes Zeichen gesehen hatte. -
die Werte unter system.host.xyz.load passen nicht wirklich zu load average 1min aus
̀top- sie wechseln viel zu schnell und stark, als dass es 1min floating average sein könnten
- der Wert ist auch deutlich höher
-
das Ansteigen der Load konnte ich (meistens 😞) reproduzieren durch
- zoomen in einem Flot chart
- arbeiten im admin an Instanzeneinstellungen
-
Wenn es zu (geregelten (0-4)) load Anstiegen kam, dauerten diese meistens ca. 30 Minuten
-
zusätzlich stieg der Speicherverbrauch im Heap des admins (leicht) an.
-
Ansonsten war weder die CPU Last noch der Speicher der Prozesse in top irgendwie auffällig.
Daraufhin habe ich mir angesehen ob ich einige Instanzen pausieren, oder unnötige Adapter deinstallieren könnte um die Ursache einzugrenzen.
-
simple api hatte ich mWn nie installiert, im Gegenteil ich hatte es nach dem Umzug bewusst deinstalliert, was zu einer deutlich niedrigeren load führte. Jetzt war es wieder da.
-
native web sockets war updatefähig, was ich gemacht habe. Auch hier hatte ich es nie installiert.
- hier habe ich eine -bisher nicht existierende- Instanz angelegt, was zu einem Portkonflikt führte, da 8084 bereits vergeben war, geändert auf 8087
Anschließend ein
iob upload allund ein rebootJetzt reagiert auch der governor wieder wie vorher und die anderen Werte im chart verhielten sich wie früher
Ab kurz nach 08:00
Den go-e Adapter hab ich jetzt deaktiviert.
Er war bei den zuletzt upgedateten dabei und wurde wegen restart loops schon mal abgeschaltet (muss kein Zusammenhang bestehen)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 - -
-
Hast du den PI5 in einem speziellen Gehäuse? Ich hatte meinen PI4 mal in ein Alu-Gehäuse gepckt und dann zeigte der die selben Sympthome.
Ro75.
SERVER = Beelink U59 16GB DDR4 RAM 512GB SSD, FB 7490, FritzDect 200+301+440, ConBee II, Zigbee Aqara Sensoren + NOUS A1Z, NOUS A1T, Philips Hue ** ioBroker, REDIS, influxdb2, Grafana, PiHole, Plex-Mediaserver, paperless-ngx (Docker), MariaDB + phpmyadmin *** VIS-Runtime = Intel NUC 8GB RAM 128GB SSD + 24" Touchscreen
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 Anmelden143
Online33.0k
Benutzende83.7k
Themen1.3m
Beiträge