VirtualBox VM lead to 100% cpu usage

After recent update somehow when I start my VM which runs Manjaro too, the VM is a bit laggy but shows no CPU usage, but the host system shows 100% CPU usage from the VirtualBox VM process thread called “ETM-0”, “ETM-1”, … Does anyone know what could it be? An AI suggested to run
”vmstat 1” command and look at “in” column, which shows high values (above 100 000) when I start the VM, and while the VM is idle.

A bit more details may produce:

$ ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head
➜  ~ ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head
    PID    PPID CMD                         %MEM %CPU
  35889    4065 /usr/lib/virtualbox/Virtual 18.8  312
   4187    3535 /app/extra/chrome --type=zy  1.0  8.8
   2390    2243 /usr/bin/gnome-shell         1.1  7.2
  32085    3535 /app/extra/chrome --type=zy  0.9  6.5
   2819    2390 /usr/bin/Xwayland :0 -rootl  0.3  5.1
   6058    3535 /app/extra/chrome --type=zy  1.0  4.6
   3050    3032 /app/extra/chrome --disable  1.4  2.8
   3655    3518 /app/extra/chrome --type=gp  0.9  2.2
  31843    3535 /app/extra/chrome --type=zy  1.0  2.1
➜  ~ 

EDIT: and after some time the VM hangs completely

Lot’s of chrome jobs, tried to stop them?

I am not sure if this was the issue, I’ll look at monday how it will behave, but the output of
vmstat 1
shows still pretty much “interrupts”:

➜  ~ vmstat 1
procs -----------memory---------- —swap-- -----io---- -system-- -------cpu-------
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
7  0      0 11620860 426496 9441916 0    0   768   408 114004  7  3 12 84  0  0  0
0  0      0 11614820 426496 9441916 0    0     0     0 127963 6734 1 3 95  0  0  0
0  0      0 11610000 426496 9441940 0    0     0     8 139227 8375 1 5 94  0  0  0
1  0      0 11596120 426496 9441940 0    0     0     0 116328 8318 1 5 94  0  0  0
0  0      0 11596120 426496 9441940 0    0     0     0 115266 7200 1 4 95  0  0  0
0  0      0 11612092 426496 9441984 0    0     0   128 114297 9490 2 4 94  0  0  0

Mod edit: made terminal output easier to read by removing the single backticks from each line and adding 3 backticks on the lines before and after the output

It sounds like you think interrupts are bad?

Interrupts are how the kernel gets notified immediately when hardware or the CPU needs attention, letting it handle I/O and multitasking without constantly checking everything.

Or maybe you think this ~120k per second is high? Was it lower before?

I loaded a VM (qemu/libvirt not virtualbox), and I seem to get around 50k in vmstat 1 (Booted Manjaro, loaded Firefox.) Still, none of this really tells us much.

I think you need to back up and troubleshoot this differently. What changed? (I don’t run Virtualbox, did that change in the update?)

What is your “lag”? The good percentage of the time when people say “lag”, it is only video related. It’s never great, but there is the lesser of the evils with their virtual video adapters.

What is your config? I have run Virtualbox in the past, but that could be some useful info for other people here.

A host (and guest) inxi -zv4 would also help. (Verbose level – v4 vs v8 should be enough since there are two of them, ~50 lines vs ~300).

I had the same problem after an update. I fixed it by changing my networking to a Bridged connection instead of the NAT that I was using before the update.

The “in” column shows about 1000 interrupts. But after VM launch it gets to about 120 k. And the VM lags a bit, but sometimes it just freezes completely without resurrection. I’ll post the output of the commands later, when I am on computer again. I thought too that it could be because of Virtual Box - NAT because htop showed the NAT thread of Virtual Box used 100 percent of CPU. But disabling the network lead still to the same amount of interrupts.

I use default Manjaro installation with gnome. The system was installed in 2021. Updates installed:

System:
Kernel: 6.12.62-1-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 15.2.1
Desktop: GNOME v: 49.2 Distro: Manjaro base: Arch Linux
Machine:
Type: Desktop System: Micro-Star product: MS-7B86 v: 3.0
serial: 
Mobo: Micro-Star model: B450 GAMING PLUS MAX (MS-7B86) v: 3.0
serial:  Firmware: UEFI vendor: American Megatrends LLC.
v: H.D3 date: 09/28/2021
Battery:
Device-1: hidpp_battery_0 model: Logitech Wireless Keyboard ERGO K860
charge: 100% (should be ignored) status: discharging
CPU:
Info: 6-core model: AMD Ryzen 5 2600 bits: 64 type: MT MCP arch: Zen+ rev: 2
cache: L1: 576 KiB L2: 3 MiB L3: 16 MiB
Speed (MHz): avg: 3794 min/max: 1550/3400 boost: enabled cores: 1: 3794
2: 3794 3: 3794 4: 3794 5: 3794 6: 3794 7: 3794 8: 3794 9: 3794 10: 3794
11: 3794 12: 3794 bogomips: 81625
Flags-basic: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a
ssse3 svm
Graphics:
Device-1: Advanced Micro Devices [AMD/ATI] Navi 23 [Radeon RX 6600/6600
XT/6600M] vendor: Gigabyte driver: amdgpu v: kernel arch: RDNA-2
bus-ID: 28:00.0
Display: wayland server: ``X.org`` v: 1.21.1.21 with: Xwayland v: 24.1.9
compositor: gnome-shell driver: X: loaded: amdgpu
unloaded: modesetting,radeon dri: radeonsi gpu: amdgpu
resolution: 2560x1440~165Hz
API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 25.3.1-arch1.2
glx-v: 1.4 direct-render: yes renderer: AMD Radeon RX 6600 XT (radeonsi
navi23 LLVM 21.1.6 DRM 3.61 6.12.62-1-MANJARO)
Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-doctor
gpu: amd-smi, nvidia-smi, radeontop x11: xprop,xrandr
Network:
Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
vendor: Micro-Star MSI driver: r8169 v: kernel port: f000 bus-ID: 22:00.0
IF: enp34s0 state: down mac: 
IF-ID-1: wlan0 state: up mac: 
Drives:
Local Storage: total: 1.36 TiB used: 664.82 GiB (47.6%)
ID-1: /dev/nvme0n1 vendor: Kingston model: SFYRS1000G size: 931.51 GiB
temp: 30.9 C
ID-2: /dev/sda vendor: Toshiba model: MQ01ACF050 size: 465.76 GiB
Partition:
ID-1: / size: 915.53 GiB used: 664.82 GiB (72.6%) fs: ext4
dev: /dev/nvme0n1p2
ID-2: /boot/efi size: 299.4 MiB used: 292 KiB (0.1%) fs: vfat
dev: /dev/nvme0n1p1
Info:
Memory: total: 32 GiB available: 31.27 GiB used: 19.6 GiB (62.7%)
Processes: 405 Uptime: 2h 15m Init: systemd
Packages: 1702 Compilers: clang: 21.1.6 gcc: 15.2.1 Shell: Zsh v: 5.9
inxi: 3.3.40

Community assistant edit: made terminal output easier to read by removing the single backticks from each line and adding 3 backticks on the lines before and after the output

High CPU usage with VirtualBox 7.2.4-1 https://bbs.archlinux.org/

Again, what were they before you were experiencing this issue? What are you comparing 120k to?

Interrupts, correlate with load, but it depends on the load. It’s a bad metric to only watch for. Other people are saying high load (CPU), and so are you!

But I won’t interrupt you if you want to go down that rabbit hole. :drum:

It seems like this could be the same problem to me?

That’s the host, which actually doesn’t tell as much..

I was about to go more into the guest configuration. The actual XML file. The most useful part about VM woes. Then the inxi inside the guest. And making sure vm-tools vbox addtions are working. (Only part of that is in the guest inxi.)

But have you ruled out this problem other people are having?

It’s better just to watch only virtualbox, and every thread it spawns. They use:

top -H -p $PID

High interrupts get reflected in those numbers too!

Maybe 120 000 interrupts are ok, I wondered, that the VM in idle state generates so much interrupts. because when the VM is not running, the amount of interrupts per second drops to about 1000. But I think I resolved the issue by installing this:

sudo pacman -S virtualbox-host-dkms

Now the CPU load of host system not 100% when the VM is idle

EDIT: no the issue is still present, but only when I switch network mode to NAT:

I think it is the same issue that was reported here:

Yes, it certainly seems to be. That being the case, we can only wait until the bug has been squashed upstream; and then of course, for the respective fixed version to filter through Arch Linux and Manjaro branches.

I note that Virtualbox 7.2.4-1 is currently in all Manjaro branches. It’s difficult to speculate as to how long the process might take.

There is likely nothing more to be achieved with this thread.

Regards.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.