Sys-net without X/gui

How much are you swapping? I used the recipe here: Minimal templates | Qubes OS
and installed just these packages on top of it: `qubes-core-agent-networking, qubes-core-agent-network-manager and qubes-core-agent-dom0-updates (mirage-firewall doesn’t handle dom0 updates).

With X, memory utilization is roughly 300MB, including the 100MB swapped. Top memory hogs are Xorg, systemd-journal and nm-applet. If you are using xterm, xterm and qubes.StartApp also take a nice chunk of memory.

And I’m using debian-minimal, but I could try fedora to see if it’s better.

This doesn’t sound right to me.

I run a debian-11-minimal based sys-net and haven’t removed X nor changed any swap configurations. I got the network manager icon in the tray and it’s fully functional and responsive. I gave sys-net 250MB memory and no maxmem (no memory balancing). The Qubes OS tray icon shows me the qube is actually only using 234MB and when I run top from within xterm I see …

top - 09:52:41 up 12:44,  1 user,  load average: 0.00, 0.01, 0.00
Tasks: 121 total,   1 running, 120 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.7 us,  0.8 sy,  0.0 ni, 98.0 id,  0.2 wa,  0.2 hi,  0.0 si,  0.2 st
MiB Mem :    180.1 total,      6.2 free,    147.0 used,     26.9 buff/cache
MiB Swap:   1024.0 total,    939.5 free,     84.5 used.     25.7 avail Mem

So there is some swapping but it can’t be very frequent or impacting performance much. CPU load for sys-net is typically between 1-4% while e.g. playing a YouTube video. In some cases I’ve seen a little over 5%, but never more than 10%.

I doubt disabling X would improve this much and I’d loose the network manager tray icon (which is doubtless useful). Not in my wildest dreams would I consider giving sys-net 600MB … for what?

1 Like

I changed swappiness to one (I like the idea) and ran top inside sys-firewall (via xterm).

Tasks: 128 total,   1 running, 127 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.2 us,  0.2 sy,  0.0 ni, 99.2 id,  0.2 wa,  0.0 hi,  0.0 si,  0.3 st
MiB Mem :   3880.5 total,   3255.7 free,    206.7 used,    418.2 buff/cache
MiB Swap:   1024.0 total,   1024.0 free,      0.0 used.   3526.0 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                       
    363 systemd+  20   0   17156   6300   5484 S   0.3   0.2   0:00.72 systemd-oomd                                                                                  
    762 user      20   0  148468  62828  55272 S   0.3   1.6   0:00.84 Xorg                                                                                          
   1019 root      20   0    7820   3864   3272 R   0.3   0.1   0:00.01 top                                                                                           
      1 root      20   0  168296  12684   9732 S   0.0   0.3   0:00.11 systemd

Doesn’t look too bad to me. I stopped top when Xorg went up there to the second place.

edit: according to qube-manager-applet sys-firewall is eating almost 4gb of RAM now. :laughing:

I moved to Mirage-firewall 0.8 (using a nightly build from a few days ago) which uses a fixed 64MB of RAM (no swapping and no balancing). Been quite happy so far.

That’s consistent with what I see - but I don’t use swap, and it doesn’t
seem to hit performance.
I do use some headless qubes, but not for memory saving.

1 Like

This is memory usage on my Debian 11 minimal sys-net qube using top and sorting by memory. This is with Xorg and xterm running, of course.

I took a look at https://github.com/mirage/qubes-mirage-firewall and http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/. Fascinating stuff.

2 Likes

If you’d like to try it, you can follow the instructions on that blog for the 0.7.1 build (the latest binary one) or, if you feel brave, try one of the nightly builds here: Job qubes-firewall on freebsd-12.

0.7.1 can only run in PV (due to a bug). The latest 0.8 nightly builds will run on PVH, which is better.

1 Like

15 posts were split to a new topic: Sys-firewall vs. sys-ids

Less ram use for sure…

But also is slower in packet filtering