Load immer über 2 mit Kernel 6.5

[nevakee]

Hallo,

seit dem der Kernel 6.5er (z.B. 6.5.11-7-pve) geladen ist, ist der Load immer über 2.
Der PBS ist eine PVE VM mit 4 Kernen und 8 GB RAM.

Gerade habe ich den alten 6.2er (6.2.16-20-pve) Kernel geladen und der Load ist direkt runter gegangen.



Ist das nur bei mir oder ist das bei noch jemanden so?

proxmox-backup: 3.0.1 (running kernel: 6.2.16-20-pve)
proxmox-backup-server: 3.1.2-1 (running version: 3.1.2)
proxmox-kernel-helper: 8.1.0
pve-kernel-6.2: 8.0.5
proxmox-kernel-6.5: 6.5.11-7
proxmox-kernel-6.5.11-7-pve-signed: 6.5.11-7
proxmox-kernel-6.5.11-6-pve-signed: 6.5.11-6
proxmox-kernel-6.2.16-20-pve: 6.2.16-20
proxmox-kernel-6.2: 6.2.16-20
ifupdown2: 3.2.0-1+pmx7
libjs-extjs: 7.0.0-4
proxmox-backup-docs: 3.1.2-1
proxmox-backup-client: 3.1.2-1
proxmox-mail-forward: 0.2.2
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.3
proxmox-widget-toolkit: 4.1.3
pve-xtermjs: 5.3.0-2
smartmontools: 7.3-pve1
zfsutils-linux: 2.2.2-pve1

 

[bluesite]

also bei mir ist die Load meist so auf 0.5 inkl laufender VMs, PBS ist zusätzlich installiert auf dem PVE



hab aktuell 6.5.11-7-pve am Laufen, einen Ryzen 5800G und 128 GB Ram

 

[nevakee]

Also ich rede jetzt nur von dem Proxmox Backup Server (VM), der betroffen ist.
Der dedizierte Server, auf dem PVE 8.1.3 mit dem Kernel 6.5 läuft, ist nicht betroffen.

 

[fiona]

Hi,
welche Prozesse sind denn für die Auslastung verantwortlich? Steht irgendwas auffälliges im Journal vom Gast (oder Host)? Bitte auch die VM-Konfiguration qm config <ID> und Versionen vom Host pveversion -v posten.

 

[nevakee]

Ich kann leider keinen Prozess finden, der die Auslastung verursacht. Testweise habe ich auch alle PBS Dienste beendet, aber der Load ist trotzdem bei 2.

Im Journal ist auch nichts auffälliges.

~ # qm config 300
agent: 1
bios: ovmf
boot: order=scsi0;ide2;net0
cores: 4
cpu: host
cpulimit: 4
efidisk0: data-nvme:vm-300-disk-0,size=1M
ide2: none,media=cdrom
memory: 8192
name: pbs01
net0: virtio=0E:D3:E7:11:F5:A0,bridge=vmbr0,firewall=1
net1: virtio=9A:0F:E4:8C:38:53,bridge=vmbr2,firewall=1
numa: 0
onboot: 1
ostype: l26
scsi0: data-nvme:vm-300-disk-1,cache=writeback,discard=on,mbps_rd=500,mbps_wr=500,size=20G,ssd=1
scsi1: data-hdd:vm-300-disk-0,backup=0,cache=writeback,discard=on,mbps_rd=100,mbps_wr=100,size=2500G
scsi2: data-hdd:vm-300-disk-1,backup=0,cache=writeback,discard=on,mbps_rd=100,mbps_wr=100,size=1750G
scsihw: virtio-scsi-pci
smbios1: uuid=4e9e4505-ad4e-48b6-a651-0cd68da3fba2
sockets: 1
startup: order=5,up=15
vcpus: 4
vmgenid: 9d9bb6cd-2898-4e35-8e72-31bfad81e6d6

~ # pveversion -v
proxmox-ve: 8.1.0 (running kernel: 6.5.11-6-pve)
pve-manager: 8.1.3 (running version: 8.1.3/b46aac3b42da5d15)
proxmox-kernel-helper: 8.1.0
pve-kernel-6.2: 8.0.5
proxmox-kernel-6.5: 6.5.11-7
proxmox-kernel-6.5.11-7-pve-signed: 6.5.11-7
proxmox-kernel-6.5.11-6-pve-signed: 6.5.11-6
proxmox-kernel-6.2.16-20-pve: 6.2.16-20
proxmox-kernel-6.2: 6.2.16-20
pve-kernel-6.2.16-3-pve: 6.2.16-3
ceph-fuse: 17.2.6-pve1+3
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx7
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-4
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.0
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.1
libpve-access-control: 8.0.7
libpve-apiclient-perl: 3.3.1
libpve-common-perl: 8.1.0
libpve-guest-common-perl: 5.0.6
libpve-http-server-perl: 5.0.5
libpve-network-perl: 0.9.5
libpve-rs-perl: 0.8.7
libpve-storage-perl: 8.0.5
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 5.0.2-4
lxcfs: 5.0.3-pve4
novnc-pve: 1.4.0-3
proxmox-backup-client: 3.1.2-1
proxmox-backup-file-restore: 3.1.2-1
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.2.2
proxmox-mini-journalreader: 1.4.0
proxmox-widget-toolkit: 4.1.3
pve-cluster: 8.0.5
pve-container: 5.0.8
pve-docs: 8.1.3
pve-edk2-firmware: 4.2023.08-2
pve-firewall: 5.0.3
pve-firmware: 3.9-1
pve-ha-manager: 4.0.3
pve-i18n: 3.1.4
pve-qemu-kvm: 8.1.2-4
pve-xtermjs: 5.3.0-2
qemu-server: 8.0.10
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.2-pve1

proxmox-backup: 3.0.1 (running kernel: 6.5.11-7-pve)
proxmox-backup-server: 3.1.2-1 (running version: 3.1.2)
proxmox-kernel-helper: 8.1.0
pve-kernel-6.2: 8.0.5
proxmox-kernel-6.5: 6.5.11-7
proxmox-kernel-6.5.11-7-pve-signed: 6.5.11-7
proxmox-kernel-6.5.11-6-pve-signed: 6.5.11-6
proxmox-kernel-6.2.16-20-pve: 6.2.16-20
proxmox-kernel-6.2: 6.2.16-20
ifupdown2: 3.2.0-1+pmx7
libjs-extjs: 7.0.0-4
proxmox-backup-docs: 3.1.2-1
proxmox-backup-client: 3.1.2-1
proxmox-mail-forward: 0.2.2
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.3
proxmox-widget-toolkit: 4.1.3
pve-xtermjs: 5.3.0-2
smartmontools: 7.3-pve1
zfsutils-linux: 2.2.2-pve1

 

[Welby]

Moin!

Ich habe nach den Feiertagen mehrere PBS Systeme aktualisiert bzw. mit dem Kernel 6.5.11-7-pve versorgt. Bei allen sprang die load nach dem reboot direkt auf eine mehr oder weniger hohen aber konstanten Wert. Dieser ging auch nach mehreren Stunden/Tagen nicht zuück, ein auslösender Prozess war auf Anhieb nicht zu finden. Nach einem Boot mit Kernelversion 6.2.16-20-pve trat das Problem nicht auf.

Abhilfe schaffte dann, auf allen Pools die Option autotrim=off zu setzen. Nach einem reboot war der Spuk vorbei. Ich habe jedoch noch nicht ausprobiert, ob ein manuell angestoßener trim der Pools ohne Probleme durchläuft oder ob sich das System daran wieder festhängt.

Evtl ein Problem mit der ZFS-Version 2.2.2? Der Kernel 6.5.11-7-pve nutzt zfs-kmod-2.2.2-pve1, Kernel 6.2.16-20-pve die Version zfs-kmod-2.1.14-pve1...

siehe Quelle
https://forum.proxmox.com/threads/p...-6-5-11-compared-to-6-2-16.137115/post-610352
https://forum.proxmox.com/threads/proxmox-ve-8-1-released.136960/post-609592