When opening second VM everything starts to become very laggy

Hi,
Happy to be on this community using this awesome OS.

I’m having an issue with it. When using the browser (for work, teams [inside the browser] and other tabs) everything seems to work well. If I’ll open another VM (personal) everything start to be laggy

work vm: 10 CPUs and 32GB Ram
personal vm: 5 CPUs and 8 GB Ram

Laptop spec:

  • Thinkpad E16 Gen 2
  • 64GB Ram
  • Ultra 7 155H

On the browser I disabled hardware acceleration but no help
What can I do to improve the performance as when I used fedora everything worked normal but now with Qubes OS 4.3.1 (latest) when opening second VM I start to have an extrem lag

Thank you

That’s a lot of RAM and VCPUs assigned per-vm. Do you really need 32G and 10 vCPUs for your work VM?

I dropped it to 6 and 24gb ram and personal to 2 and 8GB ram
I also dropped sys-firewall to 1GB (had 4Gb) and only 1 vcpu (sys-net, sys-usb and sys-firewall)

Is actually better so I guess I’ll need a laptop with a better CPU for better performance

I have 10 cores and don’t have such severe problems.
Usually it’s when swap is kicking in VM that I observe some lags (and YT video - notorious) and I have i5-1245U with low TDP that power throttle aggressively.

you have in total 10 cores not per vm
i guess if I can pin P cores to the work vm will be even better but don’t know exactly (yet) how to do so :smiley:

Found something that looks to be done by @Atrate

Thanks

Is actually better so I guess I’ll need a laptop with a better CPU for better performance

@JustBe With the Ultra 7 155H and 64G of RAM you should be able to run Qubes without many problems. That’s my hardware set-up as well and I run an up to 18 Qubes simultaneously without issues.

I do make heavy use of helper scripts that I’ve written or adapted, though :). Here’s a link to them all: GitHub - Atrate/qubes-utils: Meta-repo to provide links to Qubes utilities I've written · GitHub

As far as CPU performance goes, the real killer on new CPUs and QubesOS is thermal throttling. I’ve managed to mostly get around that by tweaking cpufreq parameters in dom0 like this (you need to do it on every boot):

xenpm set-cpufreq balance energy-perf:224

This will make the CPU draw less power which results in slightly less responsiveness when under little load, but helps a ton when under high load.

After changing the CPU and Mem everything started to work well (pined P cores to work vm as well)
But still the problem occurs when I’ll enter into a teams call (via browser) on the work vm
Everything starts to be very slow while the call

xenpm set-cpufreq balance energy-perf:224

regarding this command, it will fail on all cores with operation not supported or invalid argument

It should fail on cores 1, 3, 5, 7, 17, 19 and it’s fine to ignore that.

that’s a huge overallocation on CPU, and very likely on RAM as well.

Such machine should be able to handle 15+ VMs at the same time.
That’s what I have currently, where my sys-* VMs are limited to ~300MB the ‘real’ appVMs vary from 2G to 8G max.

For vCPU: 2 is the default and a very good starting point.

Then - if you see the increased CPU usage for any of your VM - you migh increase it accordingly.
My ‘biggest’ AppVM has 4 vCPU and 8 G of RAM - just for comparision :slight_smile:

And yes, I do use MS Teams from google chrome, and other online meetings with camera and sound on a 4K external display.

You could also read this topic:

as there are testing of various xenpm settings and it’s meaning for CPU + some udev rules to set separate settings automatically whenever you work on AC or battery.

Since the remaining slowdown is specifically during a Teams call, I would test it as a media/WebRTC problem, not only as a generic “too few cores” problem. Keep the VM at modest values first, e.g. 2-4 vCPUs and enough RAM, then watch qvm-top or xentop while joining a call.

A few variables worth changing one at a time: turn off camera background blur/effects, lower the camera resolution if Teams allows it, try the same call in Chromium vs Firefox, and test with the external display unplugged if you use one. If the whole GUI lags while one browser tab is doing video encode/decode, that points more to CPU scheduling/thermal/display overhead than to the personal VM itself.

The problem started to be so frustrated.

On team calls i don’t have the camera opened, is just screensharing (usually I’m seeing the screen for someone else, not sharing mine)

I’m seeing this problem also when playing online videos on the browser (and lags when watching a video using mpv - much better with mpv than vlc) like a youtube video

As is a work laptop, I’m working always on AC

Image is from when doing nothing, having 3 vms opened, vaulda work and personal

personal and work having google browser opened, work on teams call with screensharing

vauld having keepass opened

Perhaps these could be relevant:

I would say I passed the checks from there.

Something that I forgot to mention and probably worth it (didn’t tried w/o the external monitor)

My latop is conected to two monitors (always one activ with resolution 3440x1440 - same lag even if only this one active; second one with resolution 1920x1080

The laptop display is always off

Using google chrome but tried with firefox and same results (if not worst)

sys-usb seems unusually busy, is it normally like that for you?

When juggling multiple browsers or multiple browser windows, on Qubes or on any OS, something I do to save on CPU is leave the non-active windows displaying a blank New Tab page. Anecdotally, less costly than displaying even a simple webpage let alone something web 2.0 or animated.

no sys-usb starts to be busy when on calls on teams (my mic is mounted on the work vm but not used … not sure if is related with this as all vms starts to go high when on calls) , otherwise is at 0-3%

I’ll do this with blank page as well. Thank you

After few hours my YT qubes with 4 vcpu goes to 80-90% on every vcpu. No matter Firefox or Trivalent, need to close browser from time to time. And it affect whole system performance.