Arch Linux

Maximale CPU Last bei Lunux 6.8

tuxnix

Seit einiger Zeit, wahrscheinlich mit der Einführung vom 6.8 Kernel, beobachte ich, dass die CPU wärmer wird und der Ventilator schneller läuft. Vor zwei Tagen dann ging die CPU Last auf 100% und blieb stabil auf dieser Last von 100%, ohne dass in htop ein Prozess dafür verantwortlich war. Das Beenden aller Anwendungen brachte auch keinen Erfolg.
Nach Systemneustart ist alles normal, dieses Verhalten tritt erst später mit einiger Laufzeit auf.
Ich habe jetzt den lts kernel und header laufen und das System läuft seitdem wieder normal.

Die Frage wäre, ob das auch andere beobachtet haben, oder ob das nur bei meiner ollen CPU so ist.
Eventuell bräuchte ich Unterstützung das Verhalten zu dokumentieren um einen gescheiten bug report erstellen zu können.

CPU:

[matthias@leno1 ~]$ lscpu
Architektur:                       x86_64
  CPU Operationsmodus:             32-bit, 64-bit
  Adressgrößen:                    36 bits physical, 48 bits virtual
  Byte-Reihenfolge:                Little Endian
CPU(s):                            2
  Liste der Online-CPU(s):         0,1
Anbieterkennung:                   GenuineIntel
  Modellname:                      Intel(R) Core(TM)2 Duo CPU     P8700  @ 2.53GHz
    Prozessorfamilie:              6
    Modell:                        23
    Thread(s) pro Kern:            1
    Kern(e) pro Sockel:            2
    Sockel:                        1
    Stepping:                      10
    Übertaktung:                   aktiviert
    Skalierung der CPU(s):         85%
    Maximale Taktfrequenz der CPU: 2534,0000
    Minimale Taktfrequenz der CPU: 800,0000
    BogoMIPS:                      5055,44
    Markierungen:                  fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflus
                                   h dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon
                                    pebs bts nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse
                                   3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow flexpriority vpid dtherm 
                                   ida vnmi
Virtualisierungsfunktionen:        
  Virtualisierung:                 VT-x
Caches (Gesamtsumme):              
  L1d:                             64 KiB (2 Instanzen)
  L1i:                             64 KiB (2 Instanzen)
  L2:                              3 MiB (1 Instanz)
NUMA:                              
  NUMA-Knoten:                     1
  NUMA-Knoten0 CPU(s):             0,1
Schwachstellen:                    
  Gather data sampling:            Not affected
  Itlb multihit:                   KVM: Mitigation: VMX disabled
  L1tf:                            Mitigation; PTE Inversion; VMX EPT disabled
  Mds:                             Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
  Meltdown:                        Mitigation; PTI
  Mmio stale data:                 Unknown: No mitigations
  Reg file data sampling:          Not affected
  Retbleed:                        Not affected
  Spec rstack overflow:            Not affected
  Spec store bypass:               Vulnerable
  Spectre v1:                      Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:                      Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
  Srbds:                           Not affected
  Tsx async abort:                 Not affected

Sunshine

tuxnix

Mir ist es aufgefallen. Ich habe letztes Jahr im Nov.Archlinux Kde auf meinen Thinkpad X1 Carbon gespielt und bis vor ein paar Tagen lief auch alles stabil. Da ich einen Gesamt CPU Widget aus den Miniprogrammen oben in der Leiste angelegt hatte ist mir das aufgefallen. Des weiteren war mein Laptop vor 2 Tagen so heiß obwohl ich nur kurz ein Youtube Video angeschaut habe, das ich ihn vorsichtshalber runtergefahren habe. Und als Du mir gestern diesen Hinweis mit dem Mainboard gegeben hast, habe ich jetzt Gnome 46 mit einem Zen Kernel installiert und im Moment läuft alles ruhig. Ein Switch auf einen LTS Kernel hat übrigens das Hängenbleiben nicht verhindert.

Martin-MS

tuxnix Nach Systemneustart ist alles normal, dieses Verhalten tritt erst später mit einiger Laufzeit auf.

Wie lange muss man denn warten, bis das beobachtete Verhalten auftritt?

Ich habe hier ein T400 mit ähnlich alter CPU

Architektur:                          x86_64
CPU Operationsmodus:                  32-bit, 64-bit
Adressgrößen:                         36 bits physical, 48 bits virtual
Byte-Reihenfolge:                     Little Endian
CPU(s):                               2
Liste der Online-CPU(s):              0,1
Anbieterkennung:                      GenuineIntel
Modellname:                           Intel(R) Core(TM)2 Duo CPU     P8600  @ 2.40GHz
Prozessorfamilie:                     6
Modell:                               23
Thread(s) pro Kern:                   1
Kern(e) pro Sockel:                   2
Sockel:                               1
Stepping:                             10
Übertaktung:                          aktiviert
Skalierung der CPU(s):                33%
Maximale Taktfrequenz der CPU:        2401,0000
Minimale Taktfrequenz der CPU:        800,0000
BogoMIPS:                             4789,13

das unter Kernel
Linux 6.8.2-arch2-1 #1 SMP PREEMPT_DYNAMIC Thu, 28 Mar 2024 17:06:35 +0000

und einer uptime von
01:49:18 up 5:19, 2 users, load average: 0,02, 0,77, 1,38

keine erhöhte CPU-Last berichtet.

Hast du dir den Zustand auch mal mit top angesehen? htop ist umfangreich konfigurierbar und in den Standardeinstellungen wird nicht alles angezeigt. Das war mit seinerzeit mal aufgefallen, weil verschiedene KDE-Tools eine hohe Belastung einiger Kerne anzeigte, und htop die Prozesse dazu nicht liefern konnte, weil die Anzeige der Wait-States ausgeschaltet war. Das war damals aber ein (mittlerweile behobener) Anzeigefehler, und die angebliche hohe CPU-Belastung führte auch nicht zu einer tatsächlichen Erhöhung der CPU-Temperatur.

_Ardbeg_

Hi tuxnix,
falls es Dir etwas hilft: mir ist diesbezüglich nichts aufgefallen.
Ich leider aktuell nur unter bluetooth Problemen, ziemlich genau folgendes:

https://bbs.archlinux.org/viewtopic.php?id=293630

und

https://bbs.archlinux.org/viewtopic.php?id=293772

tuxnix

Sunshine Des weiteren war mein Laptop vor 2 Tagen so heiß obwohl ich nur kurz ein Youtube Video angeschaut habe

Ein heißes Video sozusagen?! 😉
Die Info nutzt mir bei meinem Problem leider wenig. Bei mir turnt die CPU mit hoher Auslastung weiter selbst dann, wenn ich alle Anwendungen schließe.

Martin-MS Wie lange muss man denn warten, bis das beobachtete Verhalten auftritt?

Da werde ich noch genauer darauf achten müssen, wenn ich den 6.8.2 kernel nochmals teste.
Aufgefallen ist mir zunächst einmal nur, dass auch schon kurz nach Neustart die Temperatur recht schnell über 70C° geht, bei Dingen die CPU lastig sind. Dann im Laufe der Zeit (Stunden) kommt sie kaum noch unter 70°C. Parallel dazu steigt auch die CPU Auslastung kontinuierlich bis sie dann bei 100% ist und gar nicht mehr herunter gehen möchte.

Im Vergleich dazu mit dem lts kernel hat es jetzt 50°C und die CPU-Last pendelt munter zwischen 1-15% hin und her. (Uptime: 1 day, 17 hours, 57 mins)

Kennst du ein Prog mit dem ich das protokollieren kann? Bzw. welche zusätzlichen Werte sollte ich erfassen wenn ich mir so ein testscript schreibe. (uptime, temp, cpu,?,?)

P.S.: Ja, die CPU vom T400 ist sehr ähnlich zum R500.

Martin-MS

tuxnix Kennst du ein Prog mit dem ich das protokollieren kann? Bzw. welche zusätzlichen Werte sollte ich erfassen wenn ich mir so ein testscript schreibe. (uptime, temp, cpu,?,?)

Wenn sensors die Werte bereitstellt, würde sich eine rrd-Datenbank anbieten. Dazu muss der sensord-Service laufen, der eine Logdatei erstellt, die dann mit den rrd-Tools ausgelesen und visualisiert werden kann. Läuft hier unauffällig im Hintergrund seit Jahren, weil ich seinerzeit mal im Rahmen von unregelmäßigen Systemstillständen ein Problem mit dem Netzteil vermutete und deswegen unter anderem alle Spannungen (und nebenbei auch die CPU-Temperatur) protokollierte. Die Mess- und Protokollintervalle können beim Start des Services übergeben werden, ich habe mir daraus eine Anzeige über einen Tag und eine Woche zusammengestellt. Da es sich um eine Round-Robin-Datenbank handelt, wird sie nie größer oder kann auch nicht überlaufen, weil sie immer nur die für den Beobachtungszeitraum benötigten Messwerte in einer Art Ringpuffer vorhält.
Das Wiki enthält wenig Informationen dazu, deswegen wäre https://oss.oetiker.ch/rrdtool die erste Anlaufstelle und die manpage https://man.archlinux.org/man/extra/lm_sensors/sensord.8.en
Wie es genau im Detail konfiguriert wird, weiß ich aber auch nicht mehr so genau, weil es eben schon ein paar Jahre her ist und ich mich damals mal zu dem Thema eingelesen und mich seither nicht mehr damit beschäftigt habe.

tuxnix

@Martin-MS
Danke für den Tipp. Die round-robin database schau ich mir unabhängig hiervon noch einmal später an.
Für meinen Zweck sollten Temp, CPU-Last und die laufenden Prozesse zusammen ge-log-t werden.
Habe mir hierzu jetzt ein script erstellt.

#!/bin/bash
#file->/usr/local/bin/uptime.sh

while true; do

    now=$(date --date='now' +%F' '%R)
    up=$(awk '{print "uptime "int($1/86400)"d "int($1%86400/3600)"h "int(($1%3600)/60)"m"}' /proc/uptime)
    load=$(awk '{ print $1" cpu-AL1 - "$4" aP/all" }' /proc/loadavg)
    cpusum=$(ps aux  | awk '$3<100 { SUM+=$3 } END { print SUM }')
    temp0=$(sed 's/\(.\)..$/.\1\//' /sys/class/thermal/thermal_zone0/temp)
    temp1=$(sed 's/\(.\)..$/.\1°C/' /sys/class/thermal/thermal_zone1/temp)
    fan=$(sensors | awk '$1=="fan1:" { print $2" rpm" }')
    kernel=$(awk '{ print $3}' /proc/version)

    #uptime.log
    echo "$now - $up - $temp0$temp1 - $fan - $cpusum cpu% - $load - $kernel" >> ~/uptime.log

    #uptime_ps.log
    echo "$now - $up - $kernel" >> ~/uptime_ps.log
    echo "$temp0$temp1 - $fan" >> ~/uptime_ps.log
    echo "$cpusum %cpu (SUM-ps) - $load" >> ~/uptime_ps.log
    ps aux --sort=-%cpu | awk '$3>0 && $3<100 { print $3 " " $11 }' >> ~/uptime_ps.log
    #ps -eo pid,ppid,%cpu,%mem,args --sort=-%cpu >> ~/uptime_ps.log
    echo "" >> ~/uptime_ps.log
    echo "" >> ~/uptime_ps.log

    sleep 600

done

#notice:
#(cat /proc/loadavg->Durchschnittliche Systemauslastung (cpu-AL) während der letzten 1, 5 und 15 Minuten, Anzahl der derzeit laufenden Prozesse im Verhältnis zur Gesamtzahl der Prozesse und PID des zuletzt erstellten Prozesses. Bei einem Wert von 1 pro CPU-Kern  ist das System ausgelastet.
#journalctl --since "2024-04-01 21:58" --until "2024-04-01 22:58"

Das script produziert zwei log Dateien.
Eine uptime.log für den Überblick und
eine uptime-ps.log um nach Prozessen fahnden zu können.
Außerdem lässt sich mit den Zeitstempeln das journal filtern.
z.B.: journalctl --since "2024-04-01 20:58" --until "2024-04-01 21:58"

So gerüstet stelle ich dann von lts wieder auf den aktuellen kernel um.
Mal sehen ob ich das Geschehen damit erfassen kann.

tuxnix

Auch mit dem 6.8.2 kernel läuft jetzt alles o.k.
Und das Thema ist gelöst.