RPi3 nicht zugreifbar - scheinbar extrem hohe plötzliche Systemlast

Begonnen von KölnSolar, 22 November 2016, 09:29:16

Vorheriges Thema - Nächstes Thema

KölnSolar

Zitatso stell ich mir das auch vor.
ich mir auch. Ich könnte jetzt mutmaßen, dass es bei mir seit der Umstellung auf USB-Boot ist. Aber der Auslöser muss ja was anderes sein  :o
Zitathabe leider keine passende hardware zur hand.
dito  :-[
@Werniemann: auf Deine Antwort hab ich schon lange gewartet :-* Kannst Du was zu den kworker-Prozessen(siehe Ausgangspost) sagen ?
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Wernieman

"kworker-Prozessen(siehe Ausgangspost)" ??
Finde in dem Thread nichts dazu .. was meinst Du??
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

KölnSolar

ZitatAls letzte Info noch zu meinem System: War tagelang gelaufen. Außer fhem läuft nichts an Anwendung auf der Kiste. Lt. top in der Regel deutlich unter 10% CPU. Lediglich ein paar kworker/u8:2, kworker/u8:3 kworker/u8:0 treiben Ihr "Unwesen" mit um die 10% Last. Im Inet hab ich nix gefunden, um rauszufinden, was da den Kernel zu den Prozessen veranlasst. Komischerweise wechselt die PID auch noch ?! Wären wir also bei Problemchen Nr. 3. Ich würd ja mal ohne fhem-start booten und gucken wollen, ob die kworker mit fhem im Zusammenhang stehen, aber dann hab ich ja wieder Problem Nr. 2  :'(
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Wernieman

#18
Ich darf mal aus einer kurzen Google-Suche Zitieren:
http://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu

"kworker" is a placeholder process for kernel worker threads, which perform most of the actual processing for the kernel, especially in cases where there are interrupts, timers, I/O, etc. These typically correspond to the vast majority of any allocated "system" time to running processes. It is not something that can be safely removed from the system in any way, and is completely unrelated to nepomuk or KDE (except in that these programs may make system calls, which may require the kernel to do something).

There were some reports of excessive kworker activity for relatively idle systems starting during 2.6.36 development (example discussion), and wide reports of confusion and problems with 2.6.38 (although many of these reports include the word "Natty", so I presume these people not to have used any kernel between 2.6.35 (distributed in Ubuntu 10.10) and 2.6.38 (distributed in Ubuntu 11.04).

I've found many reports of something that "fixed" this for one or another user. Most "fixes" seem to be related to updates of the kernel of various sorts. Where the update can be tracked to a specific issue, it seems to often be some driver or kernel service that has been patched to not misbehave: I have the impression that there are a very large number of things in the kernel that can cause a behaviour which is observed as excessive kworker usage.

If you find the system unusable due to excessive kworker activity, I would recommend trying to do fewer things. If you think you're not doing anything, try shutting down long-running services or timers (RSS readers, mail readers, file indexers, activity trackers, etc.). If this doesn't work, try restarting. If your system allows you to enable or disable hardware in a pre-boot environment, try turning off hardware you aren't using. If it happens on every restart before you do anything, you could try uninstalling things, but at this point you'll want to be running syscall profiling tools to track down specific applications that seem to be causing this overload.

It is to be hoped that your specific system will stop expressing this behaviour with a future kernel upgrade (and many of the most common causes of this have been solved).


Es sind also Kernel-Prozesse

Edit:
https://berens.net/2014/10/ubuntu-14-04-hohe-cpu-last-durch-kworker/

Würde aber vorher mal probieren, ob Dein Kernel auch aktuell ist!
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

KölnSolar

Danke für die Hilfe.
das
ZitatWürde aber vorher mal probieren, ob Dein Kernel auch aktuell ist!
war, glaub ich, aber keine gute Idee  :'(
Fröhlich ein apt-get update mit nachfolgendem apt-get upgrade, dann den
Zitathttps://berens.net/2014/10/ubuntu-14-04-hohe-cpu-last-durch-kworker/
gelesen und hoffnungsfroh, denn unter dem Link ist tatsächlich erstmalig davon die Rede, wie man den kworkern auf die Schliche kommt, ans Werk gegangen. Leider wurde ich schnell in meiner Euphorie gedämpft, denn den dort beschriebenen Pfad kennt der Rpi gar nicht  :( Egal, ein Versuch war es wert, da bisher alle anderen Fundstellen, nur sehr unkonkret das Thema angingen/beschreiben
ZitatI've found many reports of something that "fixed" this for one or another user. Most "fixes" seem to be related to updates of the kernel of various sorts.
Nächste Hoffnung: Nach einem reboot sind die kArbeiter verschwunden. Waren sie, denn der reboot funktionierte nicht mehr :'(
Ohne jetzt in die Details zu gehen: Erst mal mein SD-Reservesystem mit den Logs des USB-Sticks auf aktuellen Stand gebracht und das lauffähige System gebootet. Dann in Ruhe dem Boot-Fehler des Sticks nachgegangen. Aha, die Boot-Partition ist auch aktualisiert worden :'( Mir kommt die Anleitung zum Aufsetzen des USB-Boot-Modes in den Sinn. Was hatte ich da eigentlich ohne Sinn und Verstand getan ? BRANCH=next rpi-update  :o Also lud ich mir den next-Branch runter, files auf die Boot-Partition kopiert und siehe da es bootet, Log-Files wieder von SD auf USB kopiert und.... fhem läuft nicht richtig, keine USBs  :-\ Das war dann aber schnell erkannt  ;) ein sudo BRANCH=next rpi-update und voila nach guten 3 Stunden ist mein System wieder da  ;D Für....leider nichts(außer Erfahrung). Einzige Erkenntnis:
das SD-System hat die kworker nicht, während sie auf dem USB-System nicht verschwunden sind  >:(
Es bleibt also die Frage: wie kommt man den Jungs auf die Schliche ?
Und neue Frage: Ich dachte rpi-update und update/upgrade wären unterschiedliche Dinge, die sich nicht in die Quere kommen, also das eine auf den Kernel beschränkt und das andere auf "Anwendungskomponenten". Scheinbar ist dem ja nicht so, was dann wohl bedeutet: kein update/upgrade ohne nachfolgendes BRANCH=next rpi-update !
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Wernieman

Kenne ich nicht genau mit RasPi aus, aber mit Linux ... deshalb kann ich Dir bezüglich update/upgrade eines RasPis nicht helfen

das SD-System hat die kworker nicht, während sie auf dem USB-System nicht verschwunden sind
Frage:
Gleiche Kernelversion? Stichwort: "uname -a"
Gleiches System?

Wenn ja .. könnte es der USB-Zugriff sein. Dieser bedeutet schließlich auch Systemlast ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

KölnSolar

#21
ZitatGleiche Kernelversion? Stichwort: "uname -a"
Gleiches System?
Dürfte gleich sein. Mag jetzt nicht mit der SD neu testen, aber die Verzeichnisse im Github deuten für beides auf 4.4.35. Mit System meinst Du jetzt Jessie oder Wheezy oder die Hardware ? Hardware ist die selbe, mal mit SD als "normales" System, mal mit USB-als-Bootdevice gestartet. So wie ich das Ganze verstehe, ist, neben anderen Dingen, die MSD-Bootmöglichkeit bzw. eben der next-Branch eine Entwickler-/Beta-Version, die dann zukünftig in eine neue Version einfließt.
ZitatWenn ja .. könnte es der USB-Zugriff sein. Dieser bedeutet schließlich auch Systemlast ...
Was die Last anbelangt, glaub ich nicht daran. Auch die SD müsste ja dann eine sichtbare Last erzeugen. Aber natürlich kann es was mit USB zu tun haben. Ist halt schade, dass man im Nebel herumstochern muss. Dabei sind diese kworker-Prozesse ja eigentlich nur irgendwelche Prozesse, die vom Kernel ausgelöst/abgespalten werden. Und dass es da keine einfache Möglichkeit gibt herauszufinden, was die tun.... :'(

@Frank: hast Du eigentlich den next-Branch drauf und auch die kworker-Prozesse ?

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Wernieman

Du kannst per "Kernel-Debugging" bzw. perf-monitoring dieses verfolgen. ABER .. dieses ist schon für Vortgeschrittene und ich weiß nicht, wie weit Dein Wissen ist ....
(Nicht falsch verstehen)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

frank

Zitat@Frank: hast Du eigentlich den next-Branch drauf und auch die kworker-Prozesse ?
nach dem installieren des normalen jessie lite auf sd, ungefähr im august, sind mir diese prozesse auch aufgefallen.
da es meine erste bekanntschaft mit dem pi war, habe ich mich zwar auch gewundert, aber nach unbefriedigender recherche habe ich sie erstmal als "normal" bewertet.

zur zeit habe ich ein riesen desaster, da ich gar keinen zugriff mehr bekomme und fhem läuft scheinbar auch nicht mehr.  :)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Wernieman

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Intruder1956

hallo,
ich habe hier mal mitgelesen und bei mir geschaut.
Auch bei mir ist der kworker Process sehr hoch gewesen bis 45% und teilweise mehr.
habe mich die Tage immer gewundert warum Fhem zwischendurch hängt.
Habe natürlich gegoogelt aber nicht wirklich etwas über "kworker/u8:" gefunden

Dann kam mir vorhin der Gedanke, auch ich habe meinen Raspi3 von SD-Karte auf USB-Stick umgestellt und SD-Karte entfernt. Läuft
Ich bin der Meinung das es seit diesem Zeitpunkt probleme gibt.

Evtl. Lösung
Ich habe gerade eine SD-Karte in Windows neu formatiert auf fat32.
Dann habe ich den Raspi3 runtergefahren, die leere SD-Karte eingesetzt.
Raspi gestartet
Top aufgerufen
und siehe da, jetzt ist Ruhe. Kein kworker Process der ständig läuft.
kworker kommt ab und zu mal mit 0,3 % aber auch gleich wieder weg und nicht wie vorher ständig in der ersten Leiste mit 15-45 %

Also scheint es so, wenn keine SD-Karte eingesetzt wird sucht der Kernel ständig und mit viel Power der CPU nach der SD-Karte. Schlimmer als der Hund nach dem Herrchen

Gruß Werner
Zotac CI547 32GB RAM 500GB SSD,ESXI 6.5, VM-Fhem5.8, VM-ioBroker, Cul 868Mhz;Cul 433Mhz = Busware, LGW, HM-MOD-RPI-PCB, Uniroll, IT YCR-100 TMT2100,ITR-1500, LD382 mit Wifilight, ESA 2000 + SENSOR WZ SET,FS20 TFK, HM-Sec-SC, HM-CC-RT-DN,PCA301,

Wernieman

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

KölnSolar

#27
ZitatEvtl. Lösung
Lösung nicht, denn es bleibt ja die Frage, was dann die Zugriffe auf die SD sollen  :o Aber es ist ein Workaround. Mit leerer SD habe ich zwar noch kworker-Prozesse(klar !), aber keinen mehr der Performance frisst  ;D Jetzt sehe ich nur noch mein fhem und 1w ganz open in top. So soll es sein.
ZitatFrage ist ... wie sieht die fstab aus?
proc            /proc           proc    defaults          0       0
/dev/sda1  /boot           vfat    defaults          0       2
/dev/sda2  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

Zitatzur zeit habe ich ein riesen desaster, da ich gar keinen zugriff mehr bekomme und fhem läuft scheinbar auch nicht mehr.  :)
Käse, melde Dich, wenn man helfen, also etwas nachstellen kann/soll.

Edit:
Zitat(Nicht falsch verstehen)
Nee, nee passt schon. Und Kernel selber kompilieren ist mir zu heftig für das dann doch eher kleine Problem. Aber so ein verbose 5 oder stacktrace hätt ich mir irgendwie erhofft  ;D
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Wernieman

Also eigentlich sollte ein "perf-test" ohne selbstkompilieren fukntionieren. Ich habe hier den Verdacht, das der RasPi-Kernel irgendwie ... "optimiert" wurde, was bei einem booten über USB sich dann eben so negativ auswirkt ...

Nur ohne Testsystem kann ich es aktuell nicht überprüfen
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

KölnSolar

ZitatAlso eigentlich sollte ein "perf-test" ohne selbstkompilieren fukntionieren.
Joo, wenn es perf-test in der raspbian distribution gäbe  :( Hatte vorher mit "perf-test rpi" gegoogelt. Mit "perf-test linux" sieht das Ergebnis natürlich deutlich anders aus. Schade, dass Du keinen rpi hast  :'(
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt