F5F Stay Refreshed Software Operating Systems Error: CPU locked during startup on Proximox node

Error: CPU locked during startup on Proximox node

Error: CPU locked during startup on Proximox node

J
Jyok
Member
Find
144
05-05-2016, 10:41 AM
#1
I operate a server in the data center where Proxmox is installed. It's part of a cluster with ten other Proxmox nodes. The system runs a 32-core 13th Gen Intel Core i9 processor, Linux kernel version 5.15.116-1, and I'm using PVE Manager version 7.4.16. I have two 2 TB Samsung NVMe SSDs in LVM. Each virtual machine consists of a VM with 16 cores, 30 GB RAM, and 1 TB storage, both running Vicibox 8.0.1 for client use. For the past three months everything worked smoothly, but over the last two days every morning I notice the node going offline. The latest log entry shows a watchdog error on Dec 28 at 02:11:45: "CPU#31 stuck for 417s!" I have access to the system logs but not the client VM user details. I'm new to this setup and don't know what data to provide for assistance. Please let me know how to retrieve the necessary information so I can help. Thank you, anothercrash.txt
Reply
Reply
J
Jyok
05-05-2016, 10:41 AM #1

I operate a server in the data center where Proxmox is installed. It's part of a cluster with ten other Proxmox nodes. The system runs a 32-core 13th Gen Intel Core i9 processor, Linux kernel version 5.15.116-1, and I'm using PVE Manager version 7.4.16. I have two 2 TB Samsung NVMe SSDs in LVM. Each virtual machine consists of a VM with 16 cores, 30 GB RAM, and 1 TB storage, both running Vicibox 8.0.1 for client use. For the past three months everything worked smoothly, but over the last two days every morning I notice the node going offline. The latest log entry shows a watchdog error on Dec 28 at 02:11:45: "CPU#31 stuck for 417s!" I have access to the system logs but not the client VM user details. I'm new to this setup and don't know what data to provide for assistance. Please let me know how to retrieve the necessary information so I can help. Thank you, anothercrash.txt

Reply
Reply
K
Kathie2021
Junior Member
Find
8
05-05-2016, 03:03 PM
#2
@koushik401 Consider limiting allocations to 14 threads per VM. Is it really essential to assign 32 GB of memory to each virtual machine? Try switching the block scheduler from cfq/bfq to noop so the scheduler isn’t active for the guests, especially when the host handles its own disk scheduling. Run echo noop > /sys/block/sda/queue/scheduler on all main block devices in both VMs. This should enhance storage performance.
Reply
Reply
K
Kathie2021
05-05-2016, 03:03 PM #2

@koushik401 Consider limiting allocations to 14 threads per VM. Is it really essential to assign 32 GB of memory to each virtual machine? Try switching the block scheduler from cfq/bfq to noop so the scheduler isn’t active for the guests, especially when the host handles its own disk scheduling. Run echo noop > /sys/block/sda/queue/scheduler on all main block devices in both VMs. This should enhance storage performance.

Reply
Reply