Unbedienbarkeit, Speicherbedarf chromium, Systemlast

[zut]

Vor einiger Zeit hatte sich meine Wallbox komplett weggehängt. Ping ging noch, aber internes Display, Zugriff per Browser und ssh funktionierten nicht mehr. Ich musste per Spannungswegnahme einen Neustart durchführen. Gestern war die Bedienung über Display wiederum sehr langsam, der Browser zeigte nach langer Wartezeit die Meldung, dass der Neustart noch nicht abgeschlossen sei.
Ich habe mich per ssh auf die Box geschaltet - das dauerte ziemlich lange. ein

Code: Alles auswählen

top

zeigte dann eine Systemlast von über 10; einer von mehreren chromium-Prozessen hatte eine Speicherbelegung (RES) von 670MB, die anderen chromium waren auch gut dabei.
Ein Neustart hat die Sache aufgeräumt.
Jetzt nach etwa 24h siehgt es so aus:

Code: Alles auswählen

Tasks: 165 total,   1 running, 164 sleeping,   0 stopped,   0 zombie
%CPU(s):  9,8 us,  2,2 sy,  0,0 ni, 87,3 id,  0,0 wa,  0,0 hi,  0,7 si,  0,0 st
MiB Spch:    922,3 total,     71,9 free,    356,6 used,    493,8 buff/cache
MiB Swap:    100,0 total,     66,7 free,     33,2 used.    491,6 avail Spch

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL     
 1159 openwb    20   0  475252 142744  41932 S   4,0  15,1 244:00.08 chromium   
  781 openwb    20   0  689604 105996  50852 S   0,7  11,2   3:59.05 chromium   
 1640 openwb    20   0  233980  65608  17772 S  18,9   6,9 218:16.72 python3    
 1119 openwb    20   0  299588  46868  38400 S   1,3   5,0  13:13.80 chromium   
 1114 openwb    20   0  530172  44124  25500 S   0,0   4,7   7:17.32 chromium   
 1017 openwb    20   0  224388  39036  32360 S   0,0   4,1   0:00.25 chromium   
 1018 openwb    20   0  224384  38912  32300 S   0,0   4,1   0:00.18 chromium  

Randbedingungen: Harter Neustart war erforderlich mit vermutlich 2.1.4 Release; seit ein paar Tagen ist 2.1.5-Patch1 ("2024-08-30 12:39:38 +0200 [ec4ee03c6]") aufgespielt. Ich nutze das colours-Theme für den Browser. Mit der 2.1.5 auch auf dem Display der Wallbox.

Ich nehme an, daß das Thema zusammenhängt mit der zähen Bedienung, die manche schon berichtet haben. Ich meine auch gelesen zu haben, daß da für die 2.1.6 dran gearbeitet wird.
Kann ich Messungen machen / zur Verfügung stellen, die weiterhelfen?

[LutzB]

Normal ist das nicht. Wäre interessant, ob das mit dem Cards Display Theme ebenfalls auftritt.

Ich habe hier eine 2er Standalone mit Display, die immer neben meinem Entwicklungssystem auf dem aktuellen master läuft und meine vorhandenen Komponenten im Haus ausliest. Dort habe ich auch nach mehreren Tagen ohne Reboot/Update noch kein solches Verhalten feststellen können.

Die träge Bedienung, an der noch gearbeitet wird, ist lediglich ein Kommunikations- und Timingproblem mit dem Backend. Letzteres verarbeitet manche Änderungen nur im eingestellten Regelzyklus, also erst nach 10s, wenn man Pech hat.

Code: Alles auswählen

top - 16:55:20 up 1 day,  9:27,  2 users,  load average: 0,01, 0,23, 0,34
Tasks: 165 total,   1 running, 164 sleeping,   0 stopped,   0 zombie
%CPU0  :   1,0/0,7     2[                                                     ]
%CPU1  :   1,0/0,0     1[                                                     ]
%CPU2  :   7,6/1,3     9[                                                     ]
%CPU3  :   0,0/0,3     0[                                                     ]
MiB Spch: 34,3/922,3    [                                                     ]
MiB Swap: 95,0/100,0    [                                                     ]

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL     
 1206 openwb    20   0  416564  89724  33668 S  10,2   9,5 154:19.67 chromium   
 1144 openwb    20   0  523776  27964  15196 S   1,0   3,0  16:08.70 chromium   
29369 openwb    20   0   11344   3360   2680 R   1,0   0,4   0:00.15 top        
  929 openwb    20   0  683212  72400  38788 S   0,3   7,7   6:33.73 chromium   
    1 root      20   0   33884   6336   5028 S   0,0   0,7   2:13.07 systemd    
    2 root      20   0       0      0      0 S   0,0   0,0   0:00.23 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_flus+ 
    6 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 netns      
   10 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 mm_percpu+ 
   11 root      20   0       0      0      0 I   0,0   0,0   0:00.00 rcu_tasks+ 
   12 root      20   0       0      0      0 I   0,0   0,0   0:00.00 rcu_tasks+ 
   13 root      20   0       0      0      0 S   0,0   0,0   0:16.55 ksoftirqd+ 

[zut]

Bin jetzt wieder mit Cards unterwegs. Nach ein paar Tagen wenig auffällig (wobei die langsam gefilterte Sytemlast bei 1 liegt).

Code: Alles auswählen

top - 11:59:37 up 4 days, 12:05,  2 users,  load average: 0,30, 0,86, 1,08
Tasks: 170 total,   1 running, 169 sleeping,   0 stopped,   0 zombie
%CPU(s): 15,3 us,  1,8 sy,  0,0 ni, 82,7 id,  0,0 wa,  0,0 hi,  0,2 si,  0,0 st
MiB Spch:    922,3 total,     39,6 free,    328,2 used,    554,6 buff/cache
MiB Swap:    100,0 total,      0,0 free,    100,0 used.    521,0 avail Spch

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL                                                 
 1188 openwb    20   0  498440 171644  37796 S  21,7  18,2 900:12.34 chromium                                               
  976 openwb    20   0  690876  81860  38964 S   0,3   8,7  54:05.49 chromium                                               
 1506 openwb    20   0  227612  61036  10492 S   6,9   6,5 997:23.11 python3                                                
 1131 openwb    20   0  299580  29392  26416 S   0,0   3,1  23:53.41 chromium                                               
 1126 openwb    20   0  515828  28076  21208 S   1,0   3,0  59:07.76 chromium                                               
 1085 openwb    20   0  224384  21696  19680 S   0,0   2,3   0:00.20 chromium                                               
  540 root      20   0  211328  21136  17008 S   0,0   2,2   0:31.02 apache2                                                
  131 root      20   0   70380  20464  20048 S   0,0   2,2   0:10.85 systemd-journal                                        
 1084 openwb    20   0  224388  20420  19572 S   0,0   2,2   0:00.19 chromium                                               
 1137 openwb    20   0  277184  14920  12400 S   0,0   1,6   0:02.08 chromium                                               
  513 root      20   0  262944  13228  10304 S   0,0   1,4   4:54.26 Xorg                                                   
14974 openwb    20   0   20328  11900   7028 S   9,5   1,3   0:00.29 python3                                                
  983 openwb    20   0   45208  11424  11408 S   0,0   1,2   0:00.97 applet

[zut]

Ich habe vor ein paar Wochen das Wallbox-Display-Theme wieder auf Cards umgestellt und die Wallbox neu gestartet. Nach jetzt 22 Tagen habe ich wieder auf die Wallbox geschaut und fand, daß wieder ein chromium-Prozess (1188, also vmtl relativ kurz nach Booten gestartet) etwa 490MB Speicher belegte und im Mittel unter top mit 200% CPU-Last angezeigt wurde.
Ich habe den Prozess gerade gekillt und schaue mal, was weiter passiert. Der Zugriff per Browser funktioniert jedenfalls noch.

Software ist 2.1.5 Patch 1 vom 30.08.2024

[jonas1611]

Ich habe auch schon ab und zu feststellen müssen, dass das System nicht mehr reagiert. Habe dazu auch hier schon mal was geschrieben:
https://forum.openwb.de/viewtopic.php?p=117035#p117035
Bin auch gerade mit dem top Befehl auf der Suche.
Heute bei relativ kalten Temperaturen hatte der RPI 56Grad, nach reboot ist die Temperatur sofort im 5Grad gefallen.

[zut]

Nachdem ich die Chromium-Instanz abgeschossen habe, die den hohen Speicherverbrauch und die hohe CPU-Last hatte, wurde über das Display ein Neustart angeboten (Es war der Prozess für das Wallbox-Display). Mit dem neuen Chromium-Prozess war zunächst alles fein. Der neue Prozess hat jetzt etwa 2 Wochen Laufzeit und es wird wieder schlecht:

Code: Alles auswählen

top - 22:57:18 up 36 days, 23:03,  2 users,  load average: 1,59, 1,71, 2,10
Tasks: 169 total,   1 running, 168 sleeping,   0 stopped,   0 zombie
%CPU(s): 38,9 us,  6,7 sy,  0,0 ni, 53,9 id,  0,0 wa,  0,0 hi,  0,5 si,  0,0 st
MiB Spch:    922,3 total,     41,6 free,    446,0 used,    434,7 buff/cache
MiB Swap:    100,0 total,      0,0 free,    100,0 used.    397,9 avail Spch

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL                                                   
18855 openwb    20   0  577344 238384  34172 S  75,5  25,2  11984:05 chromium                                                 
 1506 openwb    20   0  281232 108692   7908 S  16,6  11,5   9131:49 python3                                                  
  976 openwb    20   0  692412  66632  22252 S   0,7   7,1 428:03.16 chromium                                                 
  131 root      20   0  103156  28508  28076 S   0,0   3,0   1:17.62 systemd-journal                                          
 1131 openwb    20   0  299580  19232  16092 S   0,3   2,0 189:32.43 chromium                                                 
  540 root      20   0  211600  19084  14788 S   0,0   2,0   4:35.74 apache2                                                  
 1126 openwb    20   0  515572  18476  15464 S  17,5   2,0   3234:35 chromium                                                 
 1085 openwb    20   0  224384   9536   7776 S   0,0   1,0   0:00.20 chromium                                                 
 1137 openwb    20   0  277184   9256   6932 S   0,0   1,0   0:15.84 chromium                                                 
  513 root      20   0  263076   8888   5588 S   4,3   0,9 696:37.21 Xorg     

Der Prozess nutzt momentan dauerhaft 75% CPU und knapp 250MB Speicher. Ich denke, hier ist im Sinne der Langzeitstabilität etwas zu tun. Entweder jede Woche nachts den Prozess terminieren und neu starten - oder besser das Speicherleck finden und schließen. Wenn keine Einwände kommen, würde ich gerne ein Issue eröffnen.

SW ist immer noch 2.1.5-patch1. Theme ist cards.

[LutzB]

Die 75% CPU-Last (nur ein Kern!, der Raspi hat max. 400% Leistung) kann ich sofort nachstellen, wenn die Ansicht "Energiefluss" angezeigt wird. Das wird vermutlich an der Animation der Linien liegen, weil wegen der Animation ständig die Anzeige aktualisiert wird. In der "Übersicht" gibt es auch jeweils einen kurzen Peak, wenn die Diagramme aktualisiert werden. Bei den Ansichten "Ladepunkte" und "Status" hingegen dümpelt Chromium unter 10% vor sich hin, ab und zu gibt es Werte um die 20%-25%. Von daher würde ich mal behaupten, dass der CPU-Bedarf an dieser Stelle normal ist. An dem grundlegen Verhalten des Browsers können wir auch schlecht etwas ändern.

Was den Speicherbedarf angeht, sehe ich keinen nennenswerten Unterschied zwischen einer Woche Laufzeit und einem Neustart. Die Werte liegen zwischen 14% und 20%.

Auffällig an Deinen Werten ist eher, dass der Swap zu 100% voll ist.

Die teilweise "zähe Bedienung" liegt an der Kommunikation mit dem Backend, da einige Topics nach Änderung erst im 10s-Intervall der Regelung wieder veröffentlicht werden. Da kann es im schlimmsten Fall durchaus mal 9s (im Mittel theoretisch 5s) dauern, bis eine Änderung auch am Display sichtbar wird. Das Thema steht auf der ToDo-Liste.

Ein Issue macht erst Sinn, wenn sich das Verhalten gezielt nachstellen lässt und auch auf einen bestimmten Prozess zurückzuführen ist. Das sehe ich aktuell noch nicht.

p.s.: Alle Daten mit aktuellen Master Branch.

[zut]

Die 10s Verzögerung war mir bewusst. Der Ursprung des Postings war aber, daß im ersten Fall die Box gar nicht mehr reagierte (kein ssh möglich) und beim zweiten Mal das ssh-Login mehrere Minuten dauerte, ich den gierigen chromium-Prozess aber noch abschießen konnte. Die letzten Male war auf dem Wallbox-Display das Cards-Theme zu sehen, mit der Übersicht (kein Energiefluss). Hier hatte ich nichts verändert, trotzdem hatte der chromium 75% CPU-Last

Dann will ich mal eine Meßreihe starten. 2.1.5-patch1, Cards auf eingebautem Display in der Übersicht, chromium vom Display abgeschossen am 2024-10-20 und am 2024-10-21 abends neu gestartet über das Display. Swap habe ich aus und wieder angestellt (die alte 100% Swap-Nutzung kam aus der Zeit, wo der Speicher vollgelaufen ist). Swap ist jetzt zu 0% genutzt.

Hier die Messreihe, geplant über 4 Wochen, neue Prozess-ID des Display-chromium ist 29815:

Code: Alles auswählen

Datum	Speicher	RES	CPU-Last	Systemload
2024-10-21	11,00 %		4,60 %	0,9
2024-10-22	12,80 %		6,30 %	0,6
2024-10-23	12,40 %	116648	14,60 %	0,8
2024-10-24	13,90 %	130360	13,90 %	0,9
2024-10-29	21,70 %	200604	35,00 %	1,6
2024-10-30	24,00 %	224152	22-107%	1,6
2024-11-03	30,80 %	286900	33-150%	2,77
2024-11-05	33,70 %	312980	44,50 %	3,17

Speicherdiagramm.png (32.52 KiB) 454 mal betrachtet

...tbc

[jonas1611]

Ich nehme euch beide mal mit rein, damit ihr es bestimmt auch zu lesen bekommt.
Bei mir war heute das System mal wieder sehr ausgelastet, z.B funktionierte die Temperaturanzeige eines Shellys nicht zuverlässig und sprang öfters auf 0,0Grad. Die Temperatur im Prozessor war sehr hoch und die Auslastung des Systems auch. Nach kill des fraglichen chromium Prozesses ging die Auslastung und die Temperatur merklich zurück.
Ich habe auch gelesen das der PI3B ab 60 Grad anfängt zu drosseln, dies würde auch die Teilweise lahme Bedienung, die viele hier im Forum beklagen erklären.

Zut auch bei mir musste ich nach dem kill Befehl das Display neu starten, was ja wohl sehr nahe legt, dass dort das Problem zu suchen ist.

Aktuell bin ich mit dem Release 2.1.5-Patch.2 unterwegs und nutze für das Display das Cards Thema. Beim Browser nutze ich aber das Color-Thema...

Code: Alles auswählen

openwb@openwb-2:~ $ sudo vcgencmd measure_temp
temp=63.4'C
openwb@openwb-2:~ $ top
top - 13:07:45 up 19 days,  2:28,  2 users,  load average: 2,46, 2,93, 3,18
Tasks: 169 total,   2 running, 167 sleeping,   0 stopped,   0 zombie
%CPU0  :  92,7/3,3    96[                                                                                ]
%CPU1  :  61,3/10,7   72[                                                                                ]
%CPU2  :  54,8/7,7    63[                                                                                ]
%CPU3  :  78,5/9,7    88[                                                                                ]
MiB Spch: 70,3/922,3    [                                                                                ]
MiB Swap:100,0/100,0    [                                                                                ]

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
 1227 openwb    20   0  794224 387844  31052 R 187,1  41,1  16512:45 chromium
 1549 openwb    20   0  263360  86568   8044 S  23,8   9,2   4665:14 python3
 1184 openwb    20   0  514304  20032  10832 S   4,0   2,1 453:44.79 chromium
  543 mosquit+  20   0   23896   4104   2700 S   2,6   0,4 445:07.92 mosquitto
  513 mosquit+  20   0   13276   3244   1968 S   1,3   0,3 285:33.10 mosquitto
12481 openwb    20   0   11344   3028   2608 R   0,7   0,3   0:02.39 top
 7122 root      20   0       0      0      0 I   0,3   0,0   0:00.01 kworker/3:0-events
29468 root      20   0       0      0      0 I   0,3   0,0   0:00.43 kworker/u8:1-events_unbound
29514 openwb    20   0  764168  18484   4424 S   0,3   2,0   2:53.31 lt-armv7l_ELF
    1 root      20   0   33888   5668   4300 S   0,0   0,6  30:10.67 systemd

[zut]

Nach 14 Tagen nimmt der Display-chromium bei mir schon wieder ganz schön Speicher und Rechenleistung in Beschlag (siehe https://forum.openwb.de/viewtopic.php?p=118317#p118317)

Für mich bemerkenswert scheint, daß die 1-Minute-Load nach dem EInloggen per ssh rapide sinkt - so als ob der Login irgendeinen Prozess unterbricht, der sonst in Dauerschleife läuft. Aktuell:

load average: 0,44, 1,33, 2,11

Bevor ich lange suche - gibt es irgend ein Watchdog-Programm, das die Systemlast, den Speicherverbrauch und die CPU-Last der ressourcenhungrigsten Prozesse per MQTT an den Mosquitto schicken kann? Dann könnte ich das mit ioBroker automatisch weiterverarbeiten.