@bob-der-1 sagte in RPI 4 Update auf ?:
load average: 1.00, 0.75, 0.68
sieht für mich aber so aus, als wenn der load schon in Ordnung wäre, jedoch wenn du darauf zugreifst und abfragst, in die Höhe geht
@bob-der-1 sagte in RPI 4 Update auf ?:
fühlt sich besser an?kann das sein.
du kannst dazu die load average oben rechts vergleichen.
wenn ich mich recht erinnere warst du da eher bei 1.5, jetzt bei unter 1
unter 1 passt eher.
https://linuxwiki.de/LoadAverage
@marc-berg sagte in RPI 4 Update auf ?:
@bob-der-1 sagte in RPI 4 Update auf ?:
Das man mal sieht wie lange die Ladezeite sind.
Als ich den Infoadapter noch installiert hatte, waren bei mir die Zeiten ähnlich. Schließlich macht der Adapter im Hintergrund einige online Abfragen. Wie sieht denn die Ladezeit bei "Übersicht" oder "Instanzen" aus?
Übersicht geht direkt auf, direkt nack Mausklick.
Instanzen 3 sek ladedauer
@oliverio sagte in RPI 4 Update auf ?:
@bob-der-1 sagte in RPI 4 Update auf ?:
fühlt sich besser an?kann das sein.
du kannst dazu die load average oben rechts vergleichen.
wenn ich mich recht erinnere warst du da eher bei 1.5, jetzt bei unter 1
unter 1 passt eher.
https://linuxwiki.de/LoadAverage
Ah Danke , wieder ein Stück schlauer.Wo müsste mein Load eher liegen mit dieser Hardware und config des Systems oder ist das nicht so simpeln zu sagen.
@ro75 sagte in RPI 4 Update auf ?:
Mal so hier reingeworfen. Weiter oben, ziehmlich am Anfang ist unter anderem zu lesen:
Error action=GetSpecificHostEntry serviceType=urn:dslforum-org:service:Hosts:1: 500 - {"code":500}
Ich habe auch den tr-64 Adapter im Einsatz. Aber ohne diese Meldung. Stimmt da ggfs. was nicht? Eventuell auch auf der Fritzbox? Das könnte dann auch die hohen Werte für fb-checkpresence erklären.
Ro75.
Ich erinnere mich an einen Beitrag da ging es um vergessene Geräte und den t-64 Adapter,nur kann ich mir keinen Reim daraus machen wegen der Adresse: dslforum.org.
das mit dem Zielwert kann man so nicht sagen.
Wenn du dir sicher bist, das deine Basis-Installation des raspi rund läuft,
dann kannst du nach 15 minuten ca mal auf top schauen.
das sind dann die werte, die dein system nur mit der grundlast des betriebssystems produziert.
dazu musst du dann aber auch die anderen softwares temporär deaktivieren. evtl hast du da noch ein mysql oder ein docker laufen, welche ja dann auch grundlast erzeugt.
wenn du dann den iobroker und wer weiß was du da noch drauf laufen hast dazu schaltest, dann erhöht sich das. aus dem unterschied siehst du dann die mehrlast.
top hat halt das problem, das es nur den wert genau dieser einen sekunde anzeigt.
in der nächsten sekunde aktiviert sich aber ein prozess, der den ganzen rechner in die tiefe reißt. das sieht man da halt nicht.
hier im forum kann man halt primär nur die iobroker themen analysieren. welche wechselwirkungen das mit anderen diensten hat ist halt sehr individuell (deswegen meine frage nach dem python, der ja nicht unerheblich last von 5-10% verursachte)
ggfs. zeigt es halt auch, das du performance mäßig am ende des systems bist und evtl bald mal nach einem upgrade auf andere hardware schaust.
alles aus der betrachtung, das die überlast nicht durch ein hard oder software problem verursacht ist.
@oliverio sagte in RPI 4 Update auf ?:
wenn du dann den iobroker und wer weiß was du da noch drauf laufen hast dazu schaltest, dann erhöht sich das. aus dem unterschied siehst du dann die mehrlast.
top hat halt das problem, das es nur den wert genau dieser einen sekunde anzeigt.
Moin,
ich hatte mal hier im Post https://forum.iobroker.net/topic/67502/rpi-4-update-auf/11?_=1692360575649 angeraten sich sysstat
zu installieren, da kann mal dann die Werte mal für einen Tag speichern und schauen, wann was passiert.
VG
Bernd
@dp20eic
Ich weis , aber dazu brauche ich etwas Zeit.
Sysstat kenne ich nicht und bin recht weit von Linux entfernt, somit muss ich lesen,versuchen und dann sehen das ich das liefere was IHR verwenden könnt.Bleibe aber dran.
Moin,
nachdem ich bisher nicht bei sysstat durchsteige, habe ich nebebei folgende Zustände des Systems mal mit top darstellen können.
Das System ohne Upnp mit python3
top - 12:20:27 up 4 days, 23:09, 1 user, load average: 1.86, 1.85, 1.52
Tasks: 189 total, 1 running, 188 sleeping, 0 stopped, 0 zombie
%Cpu(s): 10.6 us, 6.6 sy, 0.0 ni, 81.9 id, 0.0 wa, 0.0 hi, 0.9 si, 0.0 st
MiB Mem : 7811.3 total, 1334.2 free, 3473.8 used, 3003.3 buff/cache
MiB Swap: 100.0 total, 100.0 free, 0.0 used. 4214.7 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
515 iobroker 20 0 1785648 958520 42260 S 19.5 12.0 1824:34 iobroker.js-con
2909830 iobroker 20 0 746372 189304 36752 S 7.0 2.4 203:07.46 io.shelly.0
528 root 20 0 31036 17180 7796 S 5.6 0.2 412:05.09 python3
2904659 iobroker 20 0 5030288 110916 38412 S 3.6 1.4 89:46.55 io.fb-checkpres
2908285 iobroker 20 0 959412 280024 36524 S 3.6 3.5 116:09.74 io.javascript.0
2910379 iobroker 20 0 719956 112600 36564 S 2.3 1.4 36:35.81 io.sonoff.0
2910275 iobroker 20 0 700360 92652 36564 S 2.0 1.2 53:14.67 io.sma-em.0
2904187 iobroker 20 0 686728 77336 36496 S 1.7 1.0 2:25.14 io.discovery.0
2904676 iobroker 20 0 966104 104448 37808 S 1.7 1.3 4:26.52 io.alexa2.0
3371132 iobroker 20 0 1046868 179896 43684 S 1.3 2.2 0:20.95 io.admin.0
2904133 iobroker 20 0 691024 90892 36564 S 0.7 1.1 6:34.35 io.device-remin
2908691 iobroker 20 0 693648 88560 36744 S 0.7 1.1 23:37.69 io.modbus.0
3380220 pi 20 0 10040 3368 2764 R 0.7 0.0 0:00.20 top
15 root 20 0 0 0 0 I 0.3 0.0 17:58.02 rcu_preempt
100 root -51 0 0 0 0 S 0.3 0.0 14:08.88 irq/37-mmc0
2904436 iobroker 20 0 691348 89388 36460 S 0.3 1.1 20:30.36 io.energiefluss
2904758 iobroker 20 0 691868 83968 36740 S 0.3 1.0 22:29.21 io.fullybrowser
2908353 iobroker 20 0 688276 80768 36608 S 0.3 1.0 3:38.87 io.lgtv.0
2909186 iobroker 20 0 693864 85212 36508 S 0.3 1.1 24:19.54 io.ping.0
2909300 iobroker 20 0 5177604 119828 41144 S 0.3 1.5 13:47.07 io.ring.0
2909519 iobroker 20 0 719520 115736 36656 S 0.3 1.4 61:22.15 io.shelly.1
2909550 iobroker 20 0 956596 82372 37684 S 0.3 1.0 2:29.62 io.signal-cmb.0
2910506 iobroker 20 0 1090668 255440 38152 S 0.3 3.2 5:03.46 io.tankerkoenig
3374581 root 20 0 0 0 0 I 0.3 0.0 0:00.47 kworker/0:0-events
3380051 pi 20 0 16068 4784 3536 S 0.3 0.1 0:00.06 sshd
3382152 root 20 0 9848 3124 2720 S 0.3 0.0 0:00.01 top
1 root 20 0 166124 10448 7380 S 0.0 0.1 3:47.29 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.62 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 slub_flushwq
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns
8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H-kblockd
10 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
11 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_kthread
12 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_rude_kthread
13 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_trace_kthread
14 root 20 0 0 0 0 S 0.0 0.0 4:08.49 ksoftirqd/0
16 root rt 0 0 0 0 S 0.0 0.0 0:03.93 migration/0
17 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
18 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1
19 root rt 0 0 0 0 S 0.0 0.0 0:03.47 migration/1
20 root 20 0 0 0 0 S 0.0 0.0 1:46.40 ksoftirqd/1
22 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/1:0H-events_highpri
23 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2
24 root rt 0 0 0 0 S 0.0 0.0 0:03.48 migration/2
25 root 20 0 0 0 0 S 0.0 0.0 1:46.56 ksoftirqd/2
27 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/2:0H-kblockd
28 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/3
29 root rt 0 0 0 0 S 0.0 0.0 0:03.46 migration/3
30 root 20 0 0 0 0 S 0.0 0.0 1:44.28 ksoftirqd/3
32 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/3:0H-kblockd
33 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kdevtmpfs
34 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 inet_frag_wq
36 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kauditd
38 root 20 0 0 0 0 S 0.0 0
nur 64 bit light ohne Broker sieht so aus
top - 12:31:00 up 1 min, 1 user, load average: 0.28, 0.11, 0.04
Tasks: 153 total, 1 running, 152 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.1 us, 0.2 sy, 0.0 ni, 98.3 id, 1.4 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 7811.3 total, 7604.5 free, 80.9 used, 125.9 buff/cache
MiB Swap: 100.0 total, 100.0 free, 0.0 used. 7617.7 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
132 root 20 0 0 0 0 D 0.7 0.0 0:00.43 kworker/2:2+events_freezable
834 pi 20 0 10004 3468 2744 R 0.7 0.0 0:00.24 top
99 root -51 0 0 0 0 S 0.3 0.0 0:00.27 irq/37-mmc0
104 root 20 0 0 0 0 S 0.3 0.0 0:01.02 usb-storage
1 root 20 0 166116 10224 7360 S 0.0 0.1 0:02.48 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 slub_flushwq
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns
7 root 20 0 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0-rcu_gp
8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H-kblockd
9 root 20 0 0 0 0 I 0.0 0.0 0:01.18 kworker/u8:0-events_unbound
10 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
11 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_kthread
12 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_rude_kthread
13 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_trace_kthread
14 root 20 0 0 0 0 S 0.0 0.0 0:00.02 ksoftirqd/0
15 root 20 0 0 0 0 I 0.0 0.0 0:00.09 rcu_preempt
16 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
17 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
18 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1
19 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/1
20 root 20 0 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/1
21 root 20 0 0 0 0 I 0.0 0.0 0:00.00 kworker/1:0-rcu_gp
22 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/1:0H-kblockd
23 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2
24 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/2
25 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/2
26 root 20 0 0 0 0 I 0.0 0.0 0:00.00 kworker/2:0-events
27 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/2:0H-kblockd
28 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/3
29 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/3
30 root 20 0 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/3
31 root 20 0 0 0 0 I 0.0 0.0 0:00.00 kworker/3:0-events_long
32 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/3:0H-events_highpri
33 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kdevtmpfs
34 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 inet_frag_wq
35 root 20 0 0 0 0 I 0.0 0.0 0:00.04 kworker/0:1-events
36 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kauditd
37 root 20 0 0 0 0 I 0.0 0.0 0:00.03 kworker/0:2-events
38 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khungtaskd
39 root 20 0 0 0 0 I 0.0 0.0 0:00.88 kworker/u8:1-events_unbound
40 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_reaper
41 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 writeback
42 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kcompactd0
43 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kintegrityd
44 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kblockd
45 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 blkcg_punt_bio
46 root -51 0 0 0 0 S 0.0 0.0 0:00.00 watchdogd
47 root 20 0 0 0 0 I 0.0 0.0 0:00.00 kworker/u8:2
48 root 20 0 0 0 0 I 0.0 0.0 0:00.00 kworker/3:1-events_long
49 root 20 0 0 0 0 I 0.0 0.0 0:00.10 kworker/1:1-events_power_efficient
50 root 20 0 0 0 0 I 0.0 0.0 0:00.05 kworker/2:1-events
51 root 0 -20 0 0 0 I 0.0 0.0 0:00.02 kworker/3:1H-kblockd
System IoBroker Grundinstallation, nur über curl -sLf https://iobroker.net/install.sh | bash -
top - 12:39:07 up 2 min, 1 user, load average: 0.68, 0.31, 0.12
Tasks: 158 total, 1 running, 157 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.8 us, 0.5 sy, 0.0 ni, 94.2 id, 4.5 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 7811.3 total, 7325.9 free, 288.4 used, 197.0 buff/cache
MiB Swap: 100.0 total, 100.0 free, 0.0 used. 7412.2 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
506 iobroker 20 0 974008 108596 36476 S 2.7 1.4 0:12.24 iobroker.js-con
565 iobroker 20 0 985872 113040 42968 S 1.3 1.4 0:09.50 io.admin.0
880 pi 20 0 9868 3276 2736 R 0.7 0.0 0:00.04 top
50 root 0 -20 0 0 0 I 0.3 0.0 0:00.05 kworker/1:1H-kblockd
99 root -51 0 0 0 0 S 0.3 0.0 0:00.28 irq/37-mmc0
102 root 20 0 0 0 0 S 0.3 0.0 0:01.25 usb-storage
165 root 20 0 0 0 0 S 0.3 0.0 0:00.07 ext4lazyinit
167 root 20 0 0 0 0 I 0.3 0.0 0:00.57 kworker/2:4-events
394 avahi 20 0 7204 3280 2784 S 0.3 0.0 0:00.27 avahi-daemon
1 root 20 0 165216 10152 7428 S 0.0 0.1 0:02.10 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 slub_flushwq
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns
7 root 20 0 0 0 0 I 0.0 0.0 0:00.15 kworker/0:0-events
8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H-kblockd
9 root 20 0 0 0 0 I 0.0 0.0 0:01.23 kworker/u8:0-writeback
10 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
11 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_kthread
12 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_rude_kthread
13 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_trace_kthread
14 root 20 0 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/0
15 root 20 0 0 0 0 I 0.0 0.0 0:00.14 rcu_preempt
16 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
17 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
18 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1
19 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/1
20 root 20 0 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/1
21 root 20 0 0 0 0 I 0.0 0.0 0:00.00 kworker/1:0-rcu_gp
22 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/1:0H-events_highpri
23 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2
24 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/2
25 root 20 0 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/2
26 root 20 0 0 0 0 I 0.0 0.0 0:00.00 kworker/2:0-mm_percpu_wq
27 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/2:0H-kblockd
28 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/3
29 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/3
30 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/3
31 root 20 0 0 0 0 I 0.0 0.0 0:00.01 kworker/3:0-mm_percpu_wq
32 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/3:0H-kblockd
33 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kdevtmpfs
34 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 inet_frag_wq
35 root 20 0 0 0 0 I 0.0 0.0 0:00.00 kworker/0:1-events
36 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kauditd
37 root 20 0 0 0 0 I 0.0 0.0 0:00.03 kworker/0:2-cgroup_destroy
38 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khungtaskd
39 root 20 0 0 0 0 I 0.0 0.0 0:00.16 kworker/u8:1-ext4-rsv-conversion
40 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_reaper
41 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 writeback
42 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kcompactd0
43 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kintegrityd
44 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kblockd
45 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 blkcg_punt_bio
46 root -51 0 0 0 0 S 0.0 0.0 0:00.00 watchdogd
so danach ohne Python 3 ,nach wiederherstellen des Backup
top - 19:22:37 up 6:12, 1 user, load average: 1.97, 2.09, 1.18
Tasks: 180 total, 2 running, 178 sleeping, 0 stopped, 0 zombie
%Cpu(s): 10.9 us, 1.7 sy, 0.0 ni, 87.2 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
MiB Mem : 7811.3 total, 1740.3 free, 2682.9 used, 3388.2 buff/cache
MiB Swap: 100.0 total, 100.0 free, 0.0 used. 5005.6 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2102 iobroker 20 0 1668232 821924 42652 R 16.5 10.3 12:56.84 iobroker.js-con
8131 iobroker 20 0 710980 145148 36684 S 14.9 1.8 0:40.16 io.shelly.0
8922 iobroker 20 0 685084 78880 36636 S 4.6 1.0 0:08.22 io.sonoff.0
7964 iobroker 20 0 5009296 84248 38300 S 4.0 1.1 0:21.09 io.fb-checkpres
2740 iobroker 20 0 939756 278340 36524 S 2.6 3.5 2:42.75 io.javascript.0
392 avahi 20 0 7204 3308 2820 S 1.3 0.0 0:58.25 avahi-daemon
9266 iobroker 20 0 676480 70196 36476 S 1.3 0.9 0:04.53 io.device-remin
7924 iobroker 20 0 680068 76928 37048 S 0.7 1.0 0:06.46 io.deconz.0
7957 iobroker 20 0 674192 76796 36432 S 0.7 1.0 0:07.72 io.energiefluss
8076 iobroker 20 0 680384 75708 36688 S 0.7 0.9 0:09.38 io.modbus.0
8102 iobroker 20 0 677668 69644 36476 S 0.7 0.9 0:06.20 io.ping.0
8223 iobroker 20 0 677380 70160 36980 S 0.7 0.9 0:04.56 io.trashschedul
8832 pi 20 0 10040 3464 2740 R 0.7 0.0 0:00.91 top
2987 iobroker 20 0 684120 82704 36512 S 0.3 1.0 0:11.57 io.node-red.0
7734 root 20 0 0 0 0 I 0.3 0.0 0:00.14 kworker/u8:0-events_unbound
7855 root 20 0 0 0 0 I 0.3 0.0 0:02.07 kworker/1:1-mm_percpu_wq
7982 iobroker 20 0 673628 69084 36668 S 0.3 0.9 0:06.86 io.fullybrowser
8027 iobroker 20 0 5140988 87036 44400 S 0.3 1.1 0:05.27 io.lg-thinq.0
8161 iobroker 20 0 676952 70960 36412 S 0.3 0.9 0:03.70 io.signal-cmb.0
8168 iobroker 20 0 673616 68528 36476 S 0.3 0.9 0:09.82 io.sma-em.0
8795 pi 20 0 16072 4568 3328 S 0.3 0.1 0:00.07 sshd
1 root 20 0 165216 10228 7508 S 0.0 0.1 0:02.40 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.06 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 slub_flushwq
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns
8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H-kblockd
10 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
11 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_kthread
12 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_rude_kthread
13 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_trace_kthread
14 root 20 0 0 0 0 S 0.0 0.0 0:00.73 ksoftirqd/0
15 root 20 0 0 0 0 I 0.0 0.0 0:11.74 rcu_preempt
16 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
17 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
18 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1
19 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/1
20 root 20 0 0 0 0 S 0.0 0.0 0:00.20 ksoftirqd/1
22 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/1:0H-kblockd
23 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2
24 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/2
25 root 20 0 0 0 0 S 0.0 0.0 0:00.21 ksoftirqd/2
27 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/2:0H-kblockd
28 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/3
29 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/3
30 root 20 0 0 0 0 S 0.0 0.0 0:00.19 ksoftirqd/3
32 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/3:0H-events_highpri
33 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kdevtmpfs
34 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 inet_frag_wq
36 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kauditd
38 root 20 0 0 0 0 S 0.0 0.0 0:00.01 khungtaskd
40 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_reaper
41 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 writeback
42 root 20 0 0 0 0 S 0.0 0.0 0:01.71 kcompactd0
43 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kintegrity
@bob-der-1 schalt mal deine shelly Instanz aus und beobachte ob der load runter geht
mit beiden Instanzen
top - 10:29:00 up 1 day, 21:18, 1 user, load average: 1.00, 0.75, 0.68
Tasks: 179 total, 1 running, 178 sleeping, 0 stopped, 0 zombie
%Cpu(s): 9.6 us, 2.2 sy, 0.0 ni, 87.6 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st
MiB Mem : 7811.3 total, 978.3 free, 3457.5 used, 3375.6 buff/cache
MiB Swap: 100.0 total, 100.0 free, 0.0 used. 4223.0 avail Mem
ohne
top - 10:30:30 up 1 day, 21:20, 1 user, load average: 1.55, 0.94, 0.75
Tasks: 179 total, 1 running, 178 sleeping, 0 stopped, 0 zombie
%Cpu(s): 26.9 us, 5.3 sy, 0.0 ni, 66.0 id, 0.0 wa, 0.0 hi, 1.8 si, 0.0 st
MiB Mem : 7811.3 total, 1160.1 free, 3274.1 used, 3377.0 buff/cache
MiB Swap: 100.0 total, 100.0 free, 0.0 used. 4406.4 avail Mem
also nicht wirklich ein Unterschied!
@bob-der-1 sagte in RPI 4 Update auf ?:
load average: 1.00, 0.75, 0.68
sieht für mich aber so aus, als wenn der load schon in Ordnung wäre, jedoch wenn du darauf zugreifst und abfragst, in die Höhe geht
Hab wärhrend eines Backups keine verwanderung gemerkt, wild zwischen den Tabs des WEBiF rumgeklickt,scheint echt python3 gewesen zu sein.ABER einen schnelleren Sietenaufbau habe ich nicht wirklich liege gerade so bei 3-7 sek wenn ich die Instanzen aufrufe.Ich schlate Upnp ein das ich sehe ob was was passiert und wenn nicht noch mal phyton 3 drauf.
während Backup: top
top - 10:51:32 up 1 day, 21:41, 1 user, load average: 1.44, 1.02, 0.90
Tasks: 181 total, 1 running, 180 sleeping, 0 stopped, 0 zombie
%Cpu(s): 15.3 us, 3.7 sy, 0.0 ni, 78.9 id, 0.1 wa, 0.0 hi, 2.0 si, 0.0 st
MiB Mem : 7811.3 total, 1450.8 free, 3455.2 used, 2905.3 buff/cache
MiB Swap: 100.0 total, 100.0 free, 0.0 used. 4233.2 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2102 iobroker 20 0 1772112 947064 42716 S 28.8 11.8 550:21.06 iobroker.js-con
2146 iobroker 20 0 4909304 117872 43176 S 14.2 1.5 1:58.30 io.backitup.0
2740 iobroker 20 0 941000 282912 36528 S 7.0 3.5 88:24.02 io.javascript.0
7982 iobroker 20 0 692452 85264 36668 S 6.3 1.1 16:05.71 io.fullybrowser
434452 iobroker 20 0 718152 156504 36596 S 6.3 2.0 1:48.88 io.shelly.0
8168 iobroker 20 0 699164 89412 36476 S 2.6 1.1 37:40.67 io.sma-em.0
8215 iobroker 20 0 698632 103536 42052 S 2.3 1.3 18:48.39 io.tr-064.0
8922 iobroker 20 0 764660 146008 36636 S 2.3 1.8 26:12.93 io.sonoff.0
434445 iobroker 20 0 706612 104628 36588 S 2.3 1.3 0:40.87 io.shelly.1
9663 iobroker 20 0 1021592 180056 43612 S 2.0 2.3 4:16.61 io.admin.0
7957 iobroker 20 0 691792 88136 36496 S 1.0 1.1 15:26.31 io.energiefluss
8076 iobroker 20 0 692912 85736 36812 S 1.0 1.1 17:06.72 io.modbus.0
14 root 20 0 0 0 0 S 0.7 0.0 0:41.42 ksoftirqd/0
2777 iobroker 20 0 688040 79864 37940 S 0.7 1.0 1:55.61 io.email.0
8029 iobroker 20 0 686528 76928 36632 S 0.7 1.0 2:36.51 io.lgtv.0
8117 iobroker 20 0 5223328 179560 41212 S 0.7 2.2 14:39.23 io.ring.0
ich hab jetzt nur auf den average load geschaut.
hier bei iobroker grundinstallation
0.68, 0.31, 0.12
sowie prozessorlast iobroker mit 2.7% sieht für mich bei einem raspi normal aus.
ich verstehe
sobald du jetzt adapter dazuschaltest, dann geht die gesamte last hoch.
dauerhaft
1.97, 2.09, 1.18
kann ich mir schon vorstellen, das es da warm wird
iobroker immer zwischen 15 und 20% finde ich auch sehr hoch.
ich hatte es oben schon mal geschrieben.
kannst du mal bitte in der instanzsicht den expertenmodus aktivieren und dir die spalte anschauen, wo nach folgendem Schema werte stehen. das sind die eingehenden und ausgehenden ereignisse (also datenpunkte die beschrieben und gelsesen werden)
⇥129↦11
schau mal hier nach dauerhaft höheren werten, sagen wir mal >50 oder bzw. wo wirklich dauerhaft auch was passiert und sich die werte ändern
das sind die instanzen, die den iobroker mehr beschäftigen. evtl lässt sich da etwas optimieren oder fehler bereinigen.
wenn es da auch normal aussieht, dann bist du wahrscheinlich am ende der performance. wobei andere mit einem raspi 4 und vergleichbarer anzahl von adapter sagen können ob die auslastung da im vergleich passt.
auch würde ich den datenträge mal checken, nicht das da ein problem durch mehrfaches lesen , weil bestimmte teile schon defekt ergibt.
evtl auch deine eingebundenen geräte überprüfen, ob die tatsächlich so viele daten oder werte in entsprechend kurzen zeiten melden müssen.
Admin 200/10
fb-Checkp. 1600/54 wenn er scannt
js 1000/22
shelly 0 200/70
das ist über 50!
fb.checkp wüde ich mal nach einer alternative sehen.
Admin 200/10
fb-Checkp. 1600/54 wenn er scannt
js 1000/22
shelly 0 200/70
das ist über 50!
fb.checkp wüde ich mal nach einer alternative sehen.
wenn der Pi am ende ist, dann muss ich sehen!
du kannst auch mal noch nach deinen log-levels schauen von den instanzen
am besten alles auf info
aber da sind wir jetzt schon beim kleinklein optimieren.
du hast halt auch sehr viele adapter am laufen, normalerweise bei anderen ist der hauptspeicher eher am ende wie die prozessor performance.
evtl kannst da auch mal noch entschlacken was du nicht wirklich brauchst.
als raspi alternative gibt es hier ja viele threads dazu.
ich selbst habe den vorgänger von dem hier
https://geizhals.de/intel-nuc-kit-nuc7pjyhn-june-canyon-boxnuc7pjyhn-a2567349.html?hloc=at&hloc=de
bin wirklich sehr zufrieden. braucht auch nur so um die 10 watt. bei dem preis musst du noch hauptspeicher und ne ssd dazurechnen, dann ist es komplett
hat da ca 20 docker container laufen (einer davon iobroker+ 1 iobroker entwicklungscontainer und 1 iobroker testcontainer), alles schön voneinander gekapselt
wie es bei dem 7er ist weiß ich nicht, aber der 6er war auch nur mit max8GB ausgeschrieben, man kann aber 16GB reinstecken.
@oliverio und alle anderen
Nicht das ihr denkt ich lass das Thema schleifen.
Leider ist es die letzten Tage etwas besch.. gelaufen und ich musste mehr arbeiten als mir Lieb ist.
Allerdings habe ich angefangen meinen Pi mit IoB etwas aufzuräumen, aber noch nicht so tief wie ich es mir Wünsche.
FB-Checkp. will ich ja weg haben, was heisst einiges muss umgeschrieben und geändert werden.
oder ich lasse es und nehme Geld in die Hand und kaufe einen NUC.
Was das größere Problem werden würde :-).
Nach einiger Zeit habe ich heute endlich den Weg gefunden bekommen.
In einem anderen Thema KLICK MICH habe ich von @ESP8266 die Hilfe bekommendas ich nun eine richtig flotten Pi4 habe.
Was wurde gemacht:
Zuerst den Broker stoppen
dann wird der Befehl sudo init 1 ausführen , hier sollte der Pi abschmieren (tat er nicht)
Pi vom Strom nehmen, warten und neu booten.
Keine Verbesserung.
Also war der nächste Schritt den Takt auf 1600 MHz zu stellen und wieder von neuem zu beginnen.
Iob Stop
sudo init 1 ( pi schmiert ab, nicht mal ssh geht mehr )
vom Strom nehmen, warten , neu booten und dann siehe da die Bootzeit halbiert sich und die kompletten Adapter wurden innerhalb der hälfte an Zeit grün ( 40 stück).
Danke hier mal an @ESP8266 für die vielen Tipps.
ob das nun universel hilft? aber zumindest hat es bei mir aktuell einiges bewirkt.
@bob-der-1 sagte in RPI 4 Update auf ?:
sudo init 1 ( pi schmiert ab, nicht mal ssh geht mehr )
Der schmiert nicht ab, die Kiste läuft ab dann im absoluten Notbetrieb, ohne Netzwerk (Weswegen auch sshd gestoppt wird). Du kannst dich dann aber noch lokal anmelden und mit dem System hantieren. Aber auch in diesem Zustand nimmt man NICHT einfach den Strom weg! Es muss hier immer noch einsauberer Restart oder Shutdown durchgeführt werden.
Siehe auch:
https://de.wikipedia.org/wiki/Runlevel
könntest Du dies etwas genauer erläutern. Im Moment verstehe ich als Laie daraus, dass du am RunLevel etwas veränderts "was aber nichts gebracht hat" und dann mal den RPI um 6% übertaktest.
Dass dies nun die Erleuchtung sein soll, hat mich noch nicht überzeugt
a) ob 6% überhaupt spürbar sind
b) ein 24/7 System mit Heimautomatisierung außerhalb der Herstellerspec zu betreiben empfinde ich eher als subjektiv anwendbare Lösung
Ist dein System so "vermurkst" oder möchtest Du Grenzen des RPI 4 einfach leicht aufweichen?
untertakten!
Der Pi rennt mit 1800MHz wenn es der richtige ist....von Haus aus!
https://buyzero.de/blogs/news/gratis-upgrade-raspberry-pi-4-jetzt-mit-1-8ghz-statt-1-5ghz.
Das warum verstehe ich auch nur halbwegs mit dem RunLevel,perfekt erklären kann ich das nicht da sind andere sicherlich firmer.
Der Takt ist mit 1800MHz wohl Geräteabhängig nicht optimal für den Einsatz als Broker,auch wenn man das nicht braucht so kann es sein das die 1800MHz für meinen eben auf dauer nicht geschmeidig sind.
Mir machen die 1600Mhz auch nichts aus weil ich das sicherlich nicht merken werde.Was ich momentan merke ist einfach das die Performance besser ist und das schiebe ich auch auf den Takt bzw. das ich am Anfang des ganzen einen ordentlichen Kühler verbaut habe.
Ob mein System vermurkst ist lieg im Auge des Betrachters, in der Regel würde ich sagen NEIN.
Installation wurde ja mitte des Jahres ( Aug. ) komplett neu gemacht, getestet und dann erst das Backup retour gespielt
@bob-der-1 said in RPI 4 Update auf ?:
untertakten!
Ah, ok . Hatte damals früh gekauft und seitdem keinen mehr.
...Was ich momentan merke ist einfach das die Performance besser ist und das schiebe ich auch auf den Takt bzw. das ich am Anfang des ganzen einen ordentlichen Kühler verbaut habe.
Mmmh, man lernt ja nie aus, aber das geringere Taktraten bei sonst gleichen Bedingungen positiv für die Performance sind klingt neu für mich.
Ist nicht eher der Kühlkörper der Grund und dass er sonst bzw. auch bei vollem Takt und Deiner Auslastung schon die Leistung drosselt?