Whonix-Workstation 14 - increase default RAM?

Whonix-Workstation with 768 MB RAM konsole gets very slowly responsive after starting Tor Browser in Whonix 14 development version (not yet uploaded, but probably soon).

Therefore temporarily set RAM to 1024 MB RAM. Might be permanent, though.

Depends on if we find solutions to reduce RAM usage. I suspect nothing that Whonix does eats a lot RAM. Suspect is KDE.

I’ve seen KDE run on odroid C2. Even small devices nowadays have 2 GB RAM. I fear it may not be possible to keep it at 768 MB RAM usage.

Discussions about KDE vs GNOME vs LXDE vs any desktop envrionemnt should go to their own thread. Please concentrate in this thread on RAM reduction that does not involve big changes which are not doable for Whonix 14, which is already very delayed in its release cycle.

1 Like

Would probably be a good idea.
Qubes switched from KDE to XFCE a while back: Get rid of KDE, use Xfce as the default Dom0 WM/DE · Issue #2119 · QubesOS/qubes-issues · GitHub because KDE was slow, bugs …
It has been mentioned in the thread that this might depend on the KDE or plasma version. It wouldn’t surprise me if debian 9 uses the same version as Fedora back then. Anyways, KDE was always one of the more resource hungry desktop environments.

1 Like

There are still some powerful ram reduction tools on Linux you can try out first before pulling the trigger on a RAM increase. See zram for example. Its included in Debian kernels but needs to be enabled for use.


Now as far as switching to a different desktop here’s my two cents. The two dominant DE libraries are KDE and GNOME. KDE is more attractive to look at. Its not dumbed down but not hard to use. Also most of the work to optimize KDE for safety and resource use slimming would be discarded and we’d need to start from scratch. KDE doesn’t try to force its worldview on the whole Linux ecosystem. I despise GNOME’s design but most of all their control freak bullshit. See Exhibit A and B. I don’t want to empower douche-bags like that (apologies to GNOME devs who are not like this). With xfce we would still be tied to GNOME behind the scene code and the UX is atrocious. Something as simple as making a desktop shortcut is needlessly complicated. (God. What kind of name is ex-feces?)

Other ways to use zram.


To early indeed to ditch KDE. Didn’t even try yet to analyze RAM use / optimize. So let’s not start a desktop environment debate.

For comparison…

sys-whonix 14

free -m
              total        used        free      shared  buff/cache   available
Mem:            374         231           4          20         138         114
Swap:          1023           0        1023

anon-whonix 14

free -m
              total        used        free      shared  buff/cache   available
Mem:            415         219          15          11         180         174
Swap:          1023           0        1023

This is top priority before Whonix 14 release.

With too much RAM requirements, we’ll turn down lots of users. Two times 768 RAM plus 128 MB VRAM is already a lot. Increasing to 1024 MB for a single workstation is hard. Increasing even further could even be too much for users with 4096 MB RAM.

Changing to another desktop environment isn’t an option for Whonix 14. Too much work. Takes too long. Stretch based Whonix already is beyond late.

  • I am wondering if the swap file should be removed. Looks like once the swap file is being used, the system goes so slow, everyone will give up and hard reset.
  • How can the system be made fail in more clever ways rather than just freezing when RAM is full?
  • Either KDE RAM use reduction and/or zram.
1 Like

I found a detailed comparison between the different memory compression mechanisms in the kernel. They may or may not be able to help in our case.

More research is needed. Suggest a direction I should look in.

You don’t want to disable swap altogether as its counterprodctive. Try reducing its size instead among other things in these threads:

What is the minimum amount of RAM where KDE can run in a reasonable way? You could maybe decrease the default amount for the gatway so you have more for the workstation.

If the swap file gets used more it just means you are running out of RAM. Without swap the system should crash even faster.


You don’t want to disable swap altogether as its counterprodctive. Try reducing its size instead among other things in these threads:

linux - prevent system freeze/unresponsiveness due to swapping run away memory usage - Super User
oom - How do I prevent Linux from freezing when out of memory? - Server Fault

As soon as there is as little as 10 MB swap in use, system gets so slow,
that most will just hard reset. So something is wrong with it.


What is the minimum amount of RAM where KDE can run in a reasonable way? You could maybe decrease the default amount for the gatway so you have more for the workstation.

Will have to recheck but I think 768 MB is the minimum where the gateway
runs without swap. So not much to save there.

I just made some tests to lower the RAM consumption. 768 MB for the gateway indeed seems to be the minimum. With 512 MB it gets really slow and swap gets used.
On the workstation the clear winner regarding RAM consumption is plasma-shell (~20%) followed by kwin_x11 (10-15%) and krunner (8%).
Firefox + plugin container directly after boot consume ~ 40% (ca 300 MB) of the memory, which I’d consider normal.
There are also many socat instances running which are required, however, 30 of them also occupy ~ 10-15% RAM
I’m not that familiar with the KDE desktop so the following might produce unexpected results. krunner can be killed without any problems, also kactivitymanagerd, xmbedsniproxy (removes the sdwate icon in the taskbar)
This will give you maybe 15 % RAM back and using the browser with only one tab open does not show any swapping but this will likely change with more tabs. I couldn’t yet find a way to reduce the memory consumption of the plasmashell or kwin_x11.
Just an idea: The swap on the VM is slower than on the host due to overhead from the VM but might be even slower due to the encryption. Since there is only 1 CPU this might be an issue. Also zram will increase CPU consumption due to compression/decompression and many systems which are low in RAM have mostly also only a few CPU cores/lower frequency.


3 posts were merged into an existing topic: port anon-ws-disable-stacked-tor to systemd socket activation

Good stuff!

socat RAM waste should be sorted after the upgrade of anon-ws-disable-stacked-tor, which was just now uploaded to all stretch suites. (As long as 14 is testers-only, fast/risky package migration is a necessity.)

( port anon-ws-disable-stacked-tor to systemd socket activation )

krunner, all for getting rid of it. Was deactivated in Whonix 13 by package kde-lowfat. Got probably broken due to KDE upgrade of stretch. kde-lowfat was merged into anon-apps-config. Relevant files:

anon-apps-config/usr/share/anon-apps-config at master · Whonix/anon-apps-config · GitHub

Any idea how to get rid of it?

More stuff to work through from your post. :slight_smile:

1 Like

Another suggestion I see on forums is turning off desktop effects and the compositor. The thing about the compositor though is it might increase CPU load a bit since no GPU offloading is used - but I think this was always te case in VMs anyway?

Sounds ok. Why not.

At the moment RAM is the bottleneck and CPU is pretty idle? So I am not concerned about higher CPU. Also full RAM will lag the system beyond being usable. But CPU will catch up. So far the theory.

How do we turn them off using GUI for testing? They appear already not being enabled?

1 Like

System Settings > Hardware > Display and Monitor > Compositor

System Settings > Workspace > Desktop Behaviour > Desktop Effects

1 Like

After changing both of these, I got less free RAM.

Did this work for you to get more free RAM?