RPI 4 Update auf ?

[crunchip]

@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.]

@crunchip

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

[OliverIO]

@bob-der-1

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.

[bob der 1.]

@oliverio

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.

[bob der 1.]

@oliverio

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!

[OliverIO]

@bob-der-1

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.

[bob der 1.]

@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 :-).

[bob der 1.]

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.

[Thomas Braun]

@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

[Dieter_P]

@bob-der-1

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?

[bob der 1.]

@dieter_p

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

[Dieter_P]

@bob-der-1 said in RPI 4 Update auf ?:

@dieter_p

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?

[Homoran]

@dieter_p sagte in RPI 4 Update auf ?:

das geringere Taktraten bei sonst gleichen Bedingungen positiv für die Performance sind

ergibt dann Sinn, wenn der Pi throtteld.

[bob der 1.]

@dieter_p sagte in RPI 4 Update auf ?:

@bob-der-1 said in RPI 4 Update auf ?:

@dieter_p

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?

Nein eher nicht der Kühler ist im Aug eingebaut worden, bis heute war das nur mässig besser dadurch...als Performance,Temp. der CPU war direkt super.Erst heute wurde der Pi flott

[bob der 1.]

@homoran sagte in RPI 4 Update auf ?:

throtteld

ja, aber das hat er nicht!
Bei vcgencmd get_throttled war das Ergebnis normal 0x0

[ESP8266]

Wenn ich auch noch meinen Senf dazu geben darf, dann erkläre ich das kurz mit dem Übertakten. Das mit dem abruppten Killen vom Netz war meine Schuld. Also normal shutdown.
Der Pi 4 ist Standardmäßig mit 1500 MHz getaktet. Ein Bericht im Netz schreibt das der PI4 auf 1800 MHz getaktet werden kann. Dem ist aber nicht mal so. Es gibt Bauteiltoleranzen. Der eine funzt hochgeschraubt und andere eben nicht.
Ich habe auch mit 1750 MHz getestet, das war immer noch schwammig. Nun läuft er Stabil schon Wochen lang auf 1700 MHz. Das liegt auch nicht an einem vermurksten System. Der hat nur eine Handbremse angezogen und wird mit init 1 wieder gelöst.

[Thomas Braun]

@esp8266 sagte in RPI 4 Update auf ?:

Der hat nur eine Handbremse angezogen und wird mit init 1 wieder gelöst.

Das musst du Mal erklären...
RunLevel 1 startet weniger Services als RunLevel 3.
Wenn irgendwann wieder RunLevel 3 bzw multi-user.target gestartet wird werden genau die für diesen Zustand vorgesehenen Services gestartet.

[Winni]

@esp8266 Also mein pi4 mit 8gb RAM und bullseye läuft mit 1800 MHz. Ich denke das ist Standard so. Ich habe zumindest da nichts hochgetaket.

[ESP8266]

@thomas-braun , siehst doch was alles möglich ist. Wie soll ich das erklären? Das ist mir zu hoch. Ich habe nur mit experimentieren die Erfahrung gemacht...frag doch selber in den Welten der Debian-Foren. Ich selber steige da nicht durch.

[Thomas Braun]

@esp8266 sagte in RPI 4 Update auf ?:

frag doch selber in den Welten der Debian-Foren

Ich frag aber dich...

Mein Rpi 4 läuft auch mit 1800MHz stabil.