Hoher CPU-Load des Raspberry

Homoran

Wie vermutet hat die CPU noch reserve.

Das System swapped, wie apollon vermutet hat, und ide ganzen node - Prozesse deuten darauf hin, dass das System gar nicht erst in die Hufe kommt. Bei einem load von über 20 auch kein Wunder.

Vielleicht solltest du mal die Karte tauschen.
~~@crepp:~~

habe jetzt beim pi den Stecker gezogen `
Das tötet Karten!
~~@crepp:~~

und nach dem reboot `
Stecker ziehen ist kein reboot.

Gruß

Rainer

crepp

Ja ich weiss schon, aber wenn ich fast ne viertelstunde nicht das System rankomme ?

Hab noch ne 2. Karte aber die ist ein paar bytes kleiner als diese hier, da muss ich erst mal ein kpl. Backup machen. Dann werde ich sie tauschen und wieder berichten. Swap used werde ich auch mal im Auge behalten. Momentan hat sich das System wieder beruhigt (wie auch immer ?!) Kann sogar wieder im vis arbeiten…

Vielen Dank vorläufig für Eure schnelle Hilfe !

Homoran

Dann sieh dir mal die logs zu den Zeiten an, wenn es hakt.

ggf. läuft da ein Skript amok.

Gruß

Rainer

apollon77

Wenn es wirklich ein Swap-Problem ist dann gibt es meistens einen OPunkt wo das OS den verursachenden Prozess killt.

Schau mal ob du sowas im "/var/log/syslog" findest. Ich galueb der Begriff ist "OOMKiller" oder so

frankjoke

Also wenn ich mir den top-screen anschaue fallen mir folgende Diege ein:

CPUs sind mit <50% beschäftigt, das ist nicht das Problem, Raspi's mit 1GB mem haben 4 CPU's also ist da Luft nach oben.
Wenn das nach einem re-boot war sind noch immer nicht alle Adapter voll geladen ('node'-Zeilen werden in Adapter-Instanzen umgewandelt wenn sie fertig sind mit dem Start)
Es sollte kein Swap nach dem re-boot verwendet werden, hatte ich noch NIE, nur nachdem ich eventuell neue Adapter installiere oder sonstige updates durchführe!

Ich würde ein

sudo iobroker stop
sudo iobroker upgrade self
sudo iobroker start

durchführen, nach dem Stop alle node-Prozesse entfernen wenn noch welche da sind.

crepp

@fsjoke

Kein Update

@apollon77

Habe das syslog von gestern mal durchgeforstet. Insgesamt 17 Fundstellen dieses Begriffs. Heisst das jetzt das das Problem mit dem Swapping zusammenhängt ?
686_update.png
686_oom-killer.png

Zippolighter

Ich habe jetzt nicht direkt eine Lösung für Dein Problem.

Aber ich hatte genau das selbe Verhalten wie Du es beschreibst. Mehrere Minuten kein Zugriff auf das System. System kommt nach Neustart nicht auf die Füße. Arbeiten in VIS System hängt sich auf, etc. Ich hatte einen Rasperry PI 3 im Einsatz.

Ich habe dann auf Multihost umgeschwenkt. Habe auf dem Master alle notwendigen Adapter (REGA, RPC, Admin, etc ist beschrieben im Beitrag siehe Link), alle anderen auf dem Slave. Vorallem der javascript Adapter hat bei mir viele Ressourcen gebraucht.

http://forum.iobroker.net/viewtopic.php?f=8&t=9534

Die geringere Uptime vom Master ist vorhanden, da ich das System runtergefahren hatte um auf einen zweiten Master (Master Restore) den ich noch habe als Sicherung, ein Backup eingespielt habe. Die Uptime vom Slave wäre auch höher, da ist ein Stromausfall dazwischen gekommen.

Seitdem ich die Aufteilung gemacht habe, laufen die Kisten ohne Probleme super stabil. Kein Vergleich zu vorher. Dabei ist Redis noch nicht mal aktiv, da ich mit der Sicherung der States in Redis noch auf Kriegsfuß stehe.

Solltest Dir vielleicht Gedanken machen ob Du bereit bist in einen zweiten Raspi zu investieren. Bei mir hat es sich auf jeden Fall richtig gelohnt

Gruß Zippolighter

crepp

Ja danke für den Tip, das habe ich auch schon vorbereitet. Der Slave ist schon aktiv, bin nur noch nicht dazu gekommen da das jetzige Problem dazwischenkam. Hatte ich einem Beitrag weiter oben auch erwähnt.

apollon77

~~@crepp:~~

@apollon77

Habe das syslog von gestern mal durchgeforstet. Insgesamt 17 Fundstellen dieses Begriffs. Heisst das jetzt das das Problem mit dem Swapping zusammenhängt ? `

Jain. Es heißt erstmal nur das -in dem Screenshot Fall aus Sicht des os der hm-rpc Prozess vom iobroker der Verursacher von hohem Speicherverbrauch war. Erstmal nur ein Indiz.

Steht hm-rpc bei allen Fundstellen?

crepp

Nein es sind verschiedene Fehlerursachen.

sshd

rpi2

radar

hm-rpc

kthreadd

siehe Datei (Ich hab mal ein paar Einträge zusammengefasst)
686_syslog.txt

apollon77

Dann musst du auf Häufungen schauen. Das os erwischt nichts immer den hauptverursacher … falls es den in deinem Fall überhaupt gibt.

crepp

hm-rpc 1x

sshd 8x

radar 1x

kthreadd 2x

cron 4x

rpi2 1x

crepp

Kann jemand sagen was sshd für ein Prozess ist ? Zugriff über SSH ?

crepp

Hab gegen 11 den javascript adapter abgeschaltet und im vis etwas gemacht. Aktuell sieht es so aus:

Vielleicht doch ein Speicher-Problem ?

apollon77

nimm mal bitte normales "top". htop zeigt komische Dinge an

crepp

Ich habe gestern ein Image der Karte gezogen und danach war das Problem (erstmal ?) verschwunden. Ich konnte eine Stunde im vis werkeln und der Load ging nicht über 2-2,5. - sehr verwunderlich …

Ich werde das natürlich weiter im Auge behalten.

Danke für Eure Hilfe erstmal

Homoran

~~@crepp:~~

sehr verwunderlich `
Nö.

Wenn die Karte einen Schlag weg hatte und bei schreibvorgängen zu langsam war eben nicht.

Gruß Rainer

aleks-83

Hi,

ich habe auch täglich (zu unterschiedlichen Uhrzeiten) einen Absturz aufgrund zu hoher Temperatur.

Bisher konnte ich nur 1x zum entsprechenden Zeitpunkt mit putty draufschauten.

top zeigte mir den javascript und den history adapter mit sehr hoher CPU Load an.

Ich habe die beiden mal angehalten. Seitdem scheint es zu laufen.

Aber gibt es die Möglichkeit, die CPU Last eines einzelnen Tasks mitzuschreiben?

Also ich hätte quasi gerne einen Mitschrieb der beiden o.g. Adapter. geht das?

Homoran

Ich prüfe so ziemlich alles

Top (Tabelle rechts unten, rot umrahmt) gibt die cpu und speicherauslastung für jeden Prozess an.

Die System Load enthält aber auch noch die I/O Vorgänge.

So kann bei niedriger CPU Auslastung die Load trotzdem sehr hoch srin, wenn z.b. die sd karte sehr langsam ist.

Gruß Rainer

aleks-83

Danke dir.

Das ist ja quasi meine top abfrage die ich geamcht habe.

Aber ich kann ja nicht ständig den Screen beobachten.

Daher möchte ich gerne eine Verlaufsaufzeichnung der CPU Last für die beiden Prozesse.

Wenn dann der Pi abstürzt, kann ich im Verlauf oder dem GRaphen nachsehen welcher Prozess zum Zeitpunkt des Absturzes am aktivsten war.

Community Forum

NEWS

Hoher CPU-Load des Raspberry

Support us

700

32.4k

81.5k

1.3m