High CPU Usage and General Troubleshooting

[BawdyAnarchist]

I posted a couple weeks ago regarding Xpra for FreeBSD jails. I've automated the basic integration into my system, but I'm still having lingering issues, and some points I could use some clarity on.

Setup Overview

FreeBSD 14.0-RELEASE-p5 with i3wm. All workstation activities are conducted inside jails (kernel-virtualized FreeBSD containers). Host is merely a coordinator for jails.

Jails with X11, start an xpra server with the following command:
xpra start :${_socket} --socket-dir=/tmp/xpra --opengl=force --speaker=off --pulseaudio=no --notifications=no --tray=no --system-tray=no --mmap=/tmp/xpra --desktop-scaling=auto --clipboard=yes --clipboard-direction=both > /dev/null 2>&1 &

Host (which has the Xorg display) starts one xpra client per X11 jail with the following command:
xpra attach --socket-dir=/<path_to_jail>/tmp/xpra --opengl=force --speaker=off --pulseaudio=no --notifications=no --tray=no --system-tray=no --mmap=/<path_to_jail>/tmp/xpra --desktop-scaling=auto --clipboard=yes --clipboard-direction=both > /dev/null 2>&1 &'
Note: --socket-dir is being used, because otherwise --cliboard and --clipboard-direction don't seem to work.

X11 applications are started inside jails with the following command:
xpra control :${_socket} start <APP>

GPU is exposed to the jails, and logs show OpenGL is being used. Log example:

2024-03-19 15:26:25,231 OpenGL is supported on display ':104'
2024-03-19 15:26:25,231  using 'llvmpipe (LLVM 15.0.7, 256 bits)' renderer
2024-03-19 15:39:27,505 New socket connection received
2024-03-19 15:39:27,505  on '/tmp/xpra/104/socket'
2024-03-19 15:39:27,509 Handshake complete; enabling connection
2024-03-19 15:39:27,519 Python/GTK3 FreeBSD X11 client version 5.0
2024-03-19 15:39:27,519  OpenGL is enabled with NVIDIA GeForce RTX 4090/PCIe/SSE2

Primary Issues

I'm getting huge bursts of CPU. ps -axJ <jail> shows 500-1100%, sometimes up to 3600% (on a 24/48 threadripper). Particularly when switching to a new i3 workspace that has a web browser with videos, social media, and/or charting webapp. Typically it settles down to 50%-200 in about 5-10 seconds, but even just switching tabs can spike it up again. Comparing side-by-side shows a 2-10x difference in CPU usage (compared to jails that directly access the host .X11-unix socket without Xpra).

I added the options: --desktop-scaling=auto and --mmap=/tmp/xpra and it seemed like the spikes were shorter and less severe, but I'm not sure if these could be better formatted. There is intermittent fuzziness during normal workstation activities, that didnt seem to be present without scaling=auto.

I'm also getting intermittent kernel panics, which almost never happened previously. Last debug showed:

Fatal trap 12: page fault while in kernel mode
cpuid = 46; apic id = 3c
fault code = supervisor read data, page not present

Other issues

I'm not sure if --speaker=off --pulseaudio=no is being honored. Logs show:

Warning: failed to query pulseaudio using 'pactl info'
XDG_RUNTIME_DIR (/tmp) is not owned by us (uid 1001), but by uid 0! (This could e.g. happen if you try to connect to a non-root PulseAudio as a root user, over the native protocol. Don't do that.)
W: [(null)] caps.c: Normally all extra capabilities would be dropped now, but that's impossible because PulseAudio was built without capabilities support.
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

I'm not sure if --notifications=no --tray=no --system-tray=no is being honored either, as I get popups when the client connects or is disconnected. I'd prefer to suppress the popups.

With telegram-desktop, all typing inside the app is very laggy/delayed until a clipboard copy is performed (then typing is normal/immediate). Xpra starts/attaches successfully with about 140 lines in server.log. In the interest of space, here's the briefest log snippets (with line numbers included).

After launching app:

161 QBuffer::seek: Invalid pos: 605663
... 
2328 QBuffer::seek: Invalid pos: 13692809

After performing a copy operation inside the app:

2487 qt.svg: Error while inflating gzip file: SVG format check failed
...
2768 qt.svg: Error while inflating gzip file: SVG format check failed
2769 2024-03-19 17:44:48,999 client   1 @51.763 Warning: window 0x2 changed its transparency attribute
2770 2024-03-19 17:44:48,999 client   1 @51.764  from False to True, behaviour is undefined
2771 2024-03-19 17:44:49,089 Error: failed to encode h264 frame
2772 2024-03-19 17:44:49,089  using x264 video encoder:

Wrapping Up

I've tested a number of different options/configs but I'm not really sure where to troubleshoot next. I wonder if dbus could be an issue? I have dbus installed/enabled on the host and inside the jails. I've attached a full log from the jail "disp1". This should be representative of what xpra start/attach looks like for all jails (excepting the jail with telegram-desktop in it).

Thanks in advance. I know this is a long write up. Any help is appreciated.
server.log

[totaam]

start an xpra server with the following command:
xpra start :${_socket}

I'm sure this is just an artifact of your script, but this is a display number, not a socket.

--speaker=off --pulseaudio=no

You could also use --audio=no.

--desktop-scaling=auto
--tray=no

These are both client side switches and won't have any effect on a server.

--clipboard=yes --clipboard-direction=both

That's already the default, so this has no effect.

Note: --socket-dir is being used, because otherwise --cliboard and --clipboard-direction don't seem to work.

That's very unlikely, as there is no code even referring to sockets or socket-dirs in the clipboard adapters.

GPU is exposed to the jails, and logs show OpenGL is being used. Log example:
2024-03-19 15:26:25,231 OpenGL is supported on display ':104'
2024-03-19 15:26:25,231 using 'llvmpipe (LLVM 15.0.7, 256 bits)' renderer

That's the software renderer, not a GPU.

I'm getting huge bursts of CPU

Is the CPU usage really coming from xpra?
If mmap is working correctly? Xpra should be using minimal CPU. My guess is that it is not enabled as there are no mmap messages in your log sample.
Running your server with -d compress will show more.

2024-03-19 20:00:55,288 xpra X11 seamless server version 5.0.4-r0

This is well out of date.

I'm also getting intermittent kernel panics, which almost never happened previously. Last debug showed:

Kernel bug?
xpra is not reponsible for kernel paging.

I'm not sure if --speaker=off --pulseaudio=no is being honored. Logs show:

Use --audio=no.

I'm not sure if --notifications=no --tray=no --system-tray=no is being honored either, as I get popups when the client connects or is disconnected. I'd prefer to suppress the popups.

Are you sure that the popups are from xpra itself?
A client running with --notifications=no should not have the ability to send any notifications, forwarded or not.

With telegram-desktop, all typing inside the app is very laggy/delayed until a clipboard copy is performed

I have no idea what telegram-desktop is.
Screen updates should not be delayed, especially with mmap enabled - there is no relation to the clipboard at all.

After launching app:

These are not xpra messages.

2487 qt.svg: Error while inflating gzip file: SVG format check failed

Also not from xpra.

Error: failed to encode h264 frame
using x264 video encoder:

The details are missing.
The x264 encoder is very stable and has been working almost flawlessly for ~12 years...

I wonder if dbus could be an issue?

I see no sign of that here, but it is possible.

[totaam]

Not heard back, closing.
Problems are likely fixed in newer versions.