plötzlich höhere CPU-Last bei allen Linux-VMs?!

H

HalloWelt

New Member
May 21, 2023
27
1
3
Hallo, seit dem letzten PVE-Update (bei mir am Mittwoch so um 18 Uhr eingespielt) wird bei allen Linux-VMs plötzlich eine deutlich höhere CPU-Auslastung angezeigt:

Linux:
Screenshot 2025-03-16 113521.jpg

Linux:
Screenshot 2025-03-16 113552.jpg

Linux:
Screenshot 2025-03-16 113615.jpg

Bei den Windows-VMs nicht:
Screenshot 2025-03-16 113629.jpg

Ich vermute, dass es durch das PVE-Update kam, weil auch meine Telefonanalgen-VM davon betroffen ist (ebenfalls Linux), die aber definitiv kein Update am Mittwoch bekam, weil sie aus dem Support ist (die anderen Linux-VMs wurden mit PVE geupdatet).

Ist das bekannt? Ist nervig, weil die Lärmbelästigung durch die lauteren Lüfter da ist...
 
Last edited:
Hatte dasselbe "Phänomen". Kam bei mir mit dem Update von pve-qemu-kvm auf 9.2.x-x Ich bin nach 5 Stunden wieder zurück auf 9.0.2-5

CPU-209.png

Seltsamerweise habe ich damals mit TOP keinen Prozess finden können der die Last verursacht hat ....
 
Last edited:
  • Like
Reactions: HalloWelt
Die configs der VMs und (Hardware) Details über die PVE hosts wären interessant zu haben. Auch die kernel version am host und im gast wäre gut zu wissen.
 
In meinem Fall wäre das:

Code: 
PVE:    16 x AMD Ryzen 7 5700U with Radeon Graphics (1 Socket) - 32GB RAM - EFI - pve-manager/8.3.5/dac3aa88bac3f300
VM209:    Debian 12.10 (war beim Test am Mittwoch noch 12.9) - 1 CPU [host] - 1,5 GB RAM - Fileserver 45drives

Kernel
PVE:        6.11.11-1-pve
VM209:        6.1.0-17-amd64

-----------------------
VM209 config

agent: 1
boot: order=scsi0;ide2
cores: 1
cpu: host
hotplug: 0
ide2: none,media=cdrom
machine: q35
memory: 1536
meta: creation-qemu=8.0.2,ctime=1691064350
name: FileServ
net0: virtio=BC:24:11:E1:CE:87,bridge=vmbr0
numa: 0
onboot: 1
ostype: l26
scsi0: local-lvm:vm-209-disk-0,cache=writeback,discard=on,size=4G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=1b31c7b2-bd5b-468a-9c8d-e72e2a2f5dec
sockets: 1
startup: order=1,up=5
tablet: 0
tags: system
usb0: host=1058:25a3
vmgenid: 1ce2eea2-bd09-423a-b666-feb116991d8d

HW-209.png

Ich könne sofort wieder auf die neue QEMU Version wechseln, falls es etwas zu testen gibt.
 
Wenn ihr mir die Befehle sagt, mit denen ich das auslesen kann, stelle ich die Informationen gern zur Verfügung :)
 
Ich habe exakt das gleiche Problem. Meinn kleines Proxmox environment hat insbesondere bei der Home Assistant VM 50-80% mehr CPU Last seit letzten Freitag. Wie macht man den ein Roll-back zu ne alten Version?
 
Code: 
apt install pve-qemu-kvm=9.0.2-5
apt-mark hold pve-qemu-kvm=9.0.2-5

... und alle betroffenen VMs herunterfahren und neu starten (bei solchen Sachen bin ich mir nicht sicher ob ein Reboot ausreichend ist)!
 
Last edited:
juro1971 said:
den "Hold Befehl" lasse ich aber erst mal draußen....
Click to expand...
Der verhindert halt, dass bei zukünftigen Updates die qemu Version 9.2 wieder installiert wird.

Mit apt-mark unhold pve-qemu-kvm wär der Befehl auch wieder schnell rückgängig gemacht ... ;)
 
  • Like
Reactions: Johannes S
Ich sehe übrigens das gleiche Phänomen auf meiner Testmaschine.
Mit QEMU Version 9.2.x 3,5% CPU im Leerlauf, mit Version 9.0.2 1,8% CPU im Leerlauf.
Wäre mir aber ehrlich gesagt gar nicht aufgefallen...
Edit: Das tritt übrigens auch auf, wenn man trotz QEMU 9.2 den Maschinentyp fest auf 9.0 einstellt.
 
Last edited:
Ernst T. said:
Der verhindert halt, dass bei zukünftigen Updates die qemu Version 9.2 wieder installiert wird.

Mit apt-mark unhold pve-qemu-kvm wär der Befehl auch wieder schnell rückgängig gemacht ... ;)
Click to expand...
Danke Ernst, ich bin hier echt nur Laie, ich notiere mir das mal .....
 
Hi,
HalloWelt said:
Wenn ihr mir die Befehle sagt, mit denen ich das auslesen kann, stelle ich die Informationen gern zur Verfügung :)
Click to expand...
die Konfigurationsdateien kannst Du mit qm config <ID> ausgeben, wobei das <ID> mit der Nummer der VM ersetzt werden muss. Z.B. mit lscpu kannst Du informationen über die Host CPU bekommen. Kernel-Version mit uname -a.
 
Hi,
JensF said:
Ich sehe übrigens das gleiche Phänomen auf meiner Testmaschine.
Mit QEMU Version 9.2.x 3,5% CPU im Leerlauf, mit Version 9.0.2 1,8% CPU im Leerlauf.
Wäre mir aber ehrlich gesagt gar nicht aufgefallen...
Edit: Das tritt übrigens auch auf, wenn man trotz QEMU 9.2 den Maschinentyp fest auf 9.0 einstellt.
Click to expand...
juro1971 said:
Ich habe exakt das gleiche Problem. Meinn kleines Proxmox environment hat insbesondere bei der Home Assistant VM 50-80% mehr CPU Last seit letzten Freitag. Wie macht man den ein Roll-back zu ne alten Version?
Click to expand...
bitte auch die Konfigurationsdetails posten, dann kann das Problem hoffentlich schneller gefunden werden:
t.lamprecht said:
Die configs der VMs und (Hardware) Details über die PVE hosts wären interessant zu haben. Auch die kernel version am host und im gast wäre gut zu wissen.
Click to expand...
 
Last edited:
juro1971 said:
Ich habe exakt das gleiche Problem. Meinn kleines Proxmox environment hat insbesondere bei der Home Assistant VM 50-80% mehr CPU Last seit letzten Freitag. Wie macht man den ein Roll-back zu ne alten Version?
Click to expand...
Kann ich hier bei mir nicht bestätigen. Ich habe am WE auch die Proxmox Updates der letzten ~ drei Wochen installiert, sodass ich jetzt bei 8.3.5 mit 6.8.12-8-pve Kernel bin. Weder bei der CPU-Anzeige für die HA VM

Proxmox_HAVM.png

noch bei der CPU Anzeige unter HA
HA_CPU_Info.png
sehe ich da einen relevanten Anstieg der CPU Last. Schon lange nicht mit 50 % oder noch mehr %.

HA VM Konfig mit Intel i3-7100 CPU

HAVM_Konfig.png



Auch bei einer anderen 24/7 laufenden Linux VM sehe ich keinen CPU Lastanstieg sei den Proxmox Updates am WE.
Proxmox_DSMVM.png

CPU Last PVE
Proxmox_CPU.png

Anm.: Die eher hohe CPU Last ist normal und kommt daher das ich die CPU per Governor im Powersave-Modus laufen lasse. Ohne die Powersave-Einstellungen würde die CPU-Last < 10 % sein, aber dafür die Kiste dann auch mehr Strom verbrauchen. :)

Also irgendwie scheint bei mir etwas anders zu sein als bei Euch, sprich ich erkenne hier keine CPU-Laständerungen seit den letzten PVE Updates.

VG Jim
 
  • Like
Reactions: Johannes S
Hi zusammen,
hat funktioniert. Also bei läuft es jetzt wieder so wie vorher. Jetzt wieder deutlich geringer CPU Last , die Stromsteckdose zeigt jetzt auch wie er wie vorher Watt Zhalen zwischen 4,5 und 7,5 Watt an. Den Power Governor setzte ich auch ein, Stromsparmodus. Vor dem Update lief die Kiste bei mir sehr konstant über Monate bei 5,5 Watt pro Tag pro Stunde. Es laufen eine HA VM und ein Adguard Container 24/7.
I will aber aber vorsichtigt sein mit meiner Prognose. Mein Gefühl ist, das sich das gerade wieder aufschaukelt ....
VG
JuRo
 
Last edited:
fiona said:
die Konfigurationsdateien kannst Du mit qm config <ID> ausgeben, wobei das <ID> mit der Nummer der VM ersetzt werden muss. Z.B. mit lscpu kannst Du informationen über die Host CPU bekommen. Kernel-Version mit uname -a.
Click to expand...

Danke - wenn euch das bei der Fehlersuche hilft :)

Exempalrisch nur für eine der Linux-VMs, da das Verhalten bei allen gleich ist:

qm config 101
agent: 1,fstrim_cloned_disks=1
boot: order=scsi0;net0
cores: 1
cpu: x86-64-v3
memory: 3072
meta: creation-qemu=7.2.0,ctime=1685961949
name: vProxy-SRV1
net0: virtio=C6:F3:B6:C8:0A:08,bridge=vmbr10,tag=111
numa: 0
onboot: 1
ostype: l26
scsi0: local-zfs:vm-101-disk-0,discard=on,iothread=1,size=512G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=4b07dce3-8891-42b1-95f1-f8ee2b48e64c
sockets: 1
tags: dmz;ubuntu
vmgenid: f8e7bcd3-3cd1-4ef9-9a28-f898ada5fbe6

lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 46 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Vendor ID: GenuineIntel
BIOS Vendor ID: Intel
Model name: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz
BIOS Model name: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz CPU @ 2.2GHz
BIOS CPU family: 179
CPU family: 6
Model: 86
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
Stepping: 3
CPU(s) scaling MHz: 100%
CPU max MHz: 2200.0000
CPU min MHz: 800.0000
BogoMIPS: 4400.14
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclm
ulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 pti intel_ppin ssbd ibrs ib
pb stibp tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a rdseed adx smap intel_pt xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm arat pln pts vnmi md_clear flush_l
1d
Virtualization features:
Virtualization: VT-x
Caches (sum of all):
L1d: 128 KiB (4 instances)
L1i: 128 KiB (4 instances)
L2: 1 MiB (4 instances)
L3: 6 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-7
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: KVM: Mitigation: Split huge pages
L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
Mds: Mitigation; Clear CPU buffers; SMT vulnerable
Meltdown: Mitigation; PTI
Mmio stale data: Mitigation; Clear CPU buffers; SMT vulnerable
Reg file data sampling: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP conditional; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Srbds: Not affected
Tsx async abort: Mitigation; Clear CPU buffers; SMT vulnerable

uname -a
Linux hv1 6.8.12-8-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-8 (2025-01-24T12:32Z) x86_64 GNU/Linux
 
Last edited:
  • Like
Reactions: fiona
Ubuntu 24.04.2 LTS (sind alles die gleichen, wie auf meinen Screenshots im ersten Posts):
Linux vproxy-srv1 6.8.0-55-generic #57-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb 12 23:42:21 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Telefonanlagen-VM FreePBX 16 (basiert auf einem älteren CentOS):
Linux vtk1.xxx.xxx 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 25 17:23:54 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Ein ähnliches Verhalten, hat zwar eine höhere Grundlast, zeigt aber auch einen Anstieg:
Screenshot 2025-03-18 112145.jpg
 
Last edited:
Host:
  • CPU: Intel Xeon D-1736NT
  • Kernel: 6.11.11-1-pve
  • Bash: 
    Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Address sizes:                        46 bits physical, 57 bits virtual
Byte Order:                           Little Endian
CPU(s):                               16
On-line CPU(s) list:                  0-15
Vendor ID:                            GenuineIntel
BIOS Vendor ID:                       Intel(R) Corporation
Model name:                           Intel(R) Xeon(R) D-1736NT CPU @ 2.70GHz
BIOS Model name:                      Intel(R) Xeon(R) D-1736NT CPU @ 2.70GHz  CPU @ 2.7GHz
BIOS CPU family:                      178
CPU family:                           6
Model:                                108
Thread(s) per core:                   2
Core(s) per socket:                   8
Socket(s):                            1
Stepping:                             1
CPU(s) scaling MHz:                   25%
CPU max MHz:                          3500.0000
CPU min MHz:                          800.0000
BogoMIPS:                             5400.00
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 intel_ppin ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local split_lock_detect wbnoinvd dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid fsrm md_clear pconfig flush_l1d arch_capabilities
Virtualization:                       VT-x
L1d cache:                            384 KiB (8 instances)
L1i cache:                            256 KiB (8 instances)
L2 cache:                             10 MiB (8 instances)
L3 cache:                             15 MiB (1 instance)
NUMA node(s):                         1
NUMA node0 CPU(s):                    0-15
Vulnerability Gather data sampling:   Mitigation; Microcode
Vulnerability Itlb multihit:          Not affected
Vulnerability L1tf:                   Not affected
Vulnerability Mds:                    Not affected
Vulnerability Meltdown:               Not affected
Vulnerability Mmio stale data:        Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed:               Not affected
Vulnerability Spec rstack overflow:   Not affected
Vulnerability Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:             Mitigation; Enhanced / Automatic IBRS; IBPB conditional; RSB filling; PBRSB-eIBRS SW sequence; BHI SW loop, KVM SW loop
Vulnerability Srbds:                  Not affected
Vulnerability Tsx async abort:        Not affected

VM 1:
  • OS: Debian 12 @ Backports
  • Kernel: 6.12.12+bpo-amd64
  • GA: 1:9.2.2+ds-1~bpo12+1
  • Bash: 
    agent: 1
bios: ovmf
boot: order=scsi0;net0
cores: 2
cpu: host
efidisk0: local-zfs:vm-301-disk-0,efitype=4m,pre-enrolled-keys=1,size=528K
machine: q35
memory: 2048
meta: creation-qemu=6.2.0,ctime=1653266106
name: Syncthing
net0: virtio=[...],bridge=vmbr0
numa: 0
onboot: 1
ostype: l26
scsi0: local-zfs:vm-301-disk-1,discard=on,iothread=1,size=32G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=[...]
sockets: 1
tags: 24-7
vmgenid: [...]
  • 9.0.2-5 with GA: ~0,5%
  • 9.0.2-5 without GA: ~0,35%
  • 9.2.0-2 with GA: ~2,25%
  • 9.2.0-2 without GA: ~1,5%

VM 2:
  • OS: Debian 12 (TrueNAS Scale 24.10.2)
  • Kernel: 6.6.44-production+truenas
  • GA: 1:7.2+dfsg-7+deb12u6
  • Bash: 
    agent: 1
bios: ovmf
boot: order=scsi0;net0
cores: 8
cpu: host
efidisk0: local-zfs:vm-201-disk-0,efitype=4m,pre-enrolled-keys=1,size=1M
hostpci0: 0000:16:00,pcie=1
machine: q35
memory: 131072
meta: creation-qemu=8.1.5,ctime=1714481909
name: TrueNAS
net0: virtio=[...],bridge=vmbr0
numa: 0
onboot: 1
ostype: l26
scsi0: local-zfs:vm-201-disk-1,discard=on,iothread=1,size=16G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=[...]
sockets: 1
startup: order=2,up=150
tags: 24-7;pve2
vmgenid: [...]
  • 9.0.2-5 with GA: ~0,55%
  • 9.2.0-2 with GA: ~1,05% - ~1,25%

VM 3:
  • OS: FreeBSD 14.0-CURRENT (pfSense 2.7.2)
  • Bash: 
    bios: ovmf
boot: order=scsi0;net0
cores: 8
cpu: host
efidisk0: local-zfs:vm-100-disk-0,efitype=4m,pre-enrolled-keys=1,size=1M
machine: q35
memory: 4096
meta: creation-qemu=8.1.2,ctime=1700884088
name: pfSense1
net0: virtio=[...],bridge=vmbr0
net1: virtio=[...],bridge=vmbr2
net2: virtio=[...],bridge=vmbr3
numa: 0
onboot: 1
ostype: other
scsi0: local-zfs:vm-100-disk-1,discard=on,iothread=1,size=16G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=[...]
sockets: 1
startup: order=1,up=120
tags: 24-7;pve1
vmgenid: [...]
  • 9.0.2-5 without GA: ~3%
  • 9.2.0-2 without GA: ~3%

Edit: Added datapoint: "9.0.2-5 without GA" for VM 1.
 
Last edited:
  • Like
Reactions: Johannes S and fiona
You must log in or register to reply here.
Top Bottom